headers
Henri Bergius | 2 Jan 20:02
Favicon
Gravatar

Kicking the Repligard habit

Greetings!

Here is an idea about making the Midgard setup process completely  
Repligard-free. That would enable us to deprecate Repligard earlier,  
and would also make style template creation and packaging much easier.

This really calls for an mRFC, but I wanted to post the quick idea  
here as it came up on #midgard.

[20:25] bergie: torben: I've been thinking of killing m-t in favor of  
some files + "compiled" configuration snippet in /sitegroup-config.  
That's what you wanted all along, right?
[20:26] torben: yep
[20:26] torben: although i'd put that compiled config directly into a  
generated code-global
[20:26] torben: the less work you have to do, the better
[20:26] bergie: true
[20:26] torben: unless mgd_include_snippet is caught by mmp in the  
code-global element
[20:26] bergie: ...and for compatibility I could make a style that  
would provide "m-t -like" elements
[20:26] torben: the key is that mmp must catch this,
[20:27] torben: true
[20:27] bergie: ...and then upgrade tool that would make a site's  
style child style of the "m-t style"
[20:28] bergie: probably the generated hosts/root pages should have  
some parameter noting that they're MidCOM sites generated with some  
version, so they could be upgraded as needed
[20:34] torben: yeah
[20:34] torben: that should be easy
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jukka Zitting | 2 Jan 20:15
Picon
Gravatar

mRFC 0024: Full text indexing in Midgard

Hi,

I've just posted a proposal for introducing full text indexing in
Midgard core. It's available as mRFC 0024: Full text indexing in
Midgard (http://www.midgard-project.org/development/mrfc/0024.html).

Unless major complaints are raised, I'll start the vote thread
tomorrow on this list.

BR,

Jukka Zitting

--
Yukatan - http://yukatan.fi/ - info <at> yukatan.fi
Software craftmanship, JCR consulting, and Java development
Permalink | Reply | 10 comments |
headers
Henri Bergius | 3 Jan 09:13
Favicon
Gravatar

Ideas about in-place editing with datamanager

Greetings!

This is still an incomplete draft, but just to give you an idea what  
I'm planning.

Oh, and another thing. With this plan I would propose making  
Prototype the default JS/AJAX library of MidCOM. We duplicate lots of  
its functionalities now in o.o.helpers, but that can be changed.

Edit-in-place for midcom.helper.datamanager
===========================================

This is a specification on how to enable in-place editing in any  
MidCOM view utilizing the midcom.helper.datamanager component. This  
would make specific editing screens partially obsolete and greatly  
improve the MidCOM user experience. Obviously, like all AJAX  
functionalities, this should be kept optional.

## Inspiration

I've been thinking about this ever since seeing the [Usable  
XMLHttpRequest in Practice][2] article and implementing some of the  
AJAX in-place editors (hour reporting and group member titles) in  
OpenPsa2.

What finally got me into action, however, was the simple tutorial on  
[Edit-in-Place at 24 ways][1].

## Why Datamanager 1?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Torben Nehmer | 3 Jan 09:36
Gravatar

Re: mRFC 0024: Full text indexing in Midgard


Hi Jukka,

--Jukka Zitting wrote on 2006-01-02 20:15:
> I've just posted a proposal for introducing full text indexing in Midgard 
> core. It's available as mRFC 0024: Full text indexing in Midgard 
> (http://www.midgard-project.org/development/mrfc/0024.html).

A few comments (especially in respect of current MidCOM indexing semantics):

> The proposed full text index shall be a Lucene index directory residing on 
> the host that runs the Midgard applications. If there are multiple web 
> frontend hosts accessing a shared backend database, then each frontend shall
> have its own full text index.

What is a "web frontend" in this context? A Host?

You are saying that "Each Midgard database shall have its own full text index".
This is a bit of a change compared to the current situation where each logical
site (which could be driven by more then one host) has its own index. You can
basically configure this using the indexname configuration directive (which
defaults to hostname:port).

> Parameters and attachment are treated as object properties in the full text
> index. Parameters are included as virtual properties named
> "parameter:domain:name", and attachments (whose content can be extracted) as
> properties named "attachment:name". All link fields are stored as GUID entries
> in the full text index.

Right now, this'll change indexed field names. The current index is not tied to
(Continue reading)

Permalink | Reply | 6 comments |
headers
Torben Nehmer | 3 Jan 09:49
Gravatar

Re: Following links in QB


Hi there,

--Jukka Zitting wrote on 2005-12-30 14:11:
> Currently the query builder only has limited supports for link 
> properties, namely the dot syntax in add_constraint(). I'd like to 
> propose the following new methods as an advanced version of the join() 
> method proposed earlier by Piotras.
> [...]
>       *    $qb = new MidgardQueryBuilder("midgard_article");
>       *    $subqb = $qb->forward_join("author");
>       *    $subqb->add_constraint("username", "=", "foo");
>       *    $qb->execute(); // Returns all articles authored by "foo"
> [...]

Why not sticking to the dot-syntax?

$qb->add_constraint("author.username", "=", "foo"); looks much easier to me and
is equally readable.

The main problem I see here is integration with the current ACL implementation,
which is not possible unless we start moving ACL to the core.

Reason:

The Subquery must be ACL-checked as well as the main Query. Not in all cases the
objects returned by the main query will be childs in terms of object hierarchy
of the subqueries object (in which case ACL would implicitly work correctly).

Especally with memberships and similar relationships, this must be taken into
(Continue reading)

Permalink | Reply | 2 comments |
headers
Torben Nehmer | 3 Jan 10:10
Gravatar

Re: Ideas about in-place editing with datamanager


Hi,

--Henri Bergius wrote on 2006-01-03 09:13:
> Edit-in-place for midcom.helper.datamanager

A few thoughts, already given in IRC, but I want to document them here.

1st of all, I don't see AJAX as the golden egg of web usability. AJAX is a fine
thing if applied in well controlled doses where it makes sense. But generally
doing all edits with ajax is something I very strongly discourage. While AJAX is
(currently) certainly a Hype, it has to be seen if it establishes itself.

Right now, the only AJAX interface I find intuitive is the search dropdown of
Google.

All AJAXes I have seen in MidCOM are poor when it comes down to user experience,
all of them constantly left me wondering "what can I do here", "which piece of
(not emphaised) text do I have to click to uncover another easter egg" etc. Even
the contact chooser, while in itself a good thing(tm), made me looking at it
quirkily, as it failed now and then (bugs hopefully fixed nowadays) and was very
 slow. (Besides missing, easily visible cues in the UI).

To quote Jason Fried [1] (also referenced on [2]):

> However, let's proceed with caution. What we're talking about is technology, not
> the user experience. Ajax-based apps certainly have the potential to produce a
> better user experience, but good experiences never come by default. Good
> experiences aren't plugged in. Good experiences are crafted by thinking about
> people, not technology.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Piotras | 3 Jan 10:20

Re: mRFC 0024: Full text indexing in Midgard

Torben Nehmer <torben@...> wrote:

Hi,

My knowledge about indexing services is NULL , so forgive me my ignorance ( if happens ).

> > The proposed full text index shall be a Lucene index directory residing on 
> > the host that runs the Midgard applications. If there are multiple web 
> > frontend hosts accessing a shared backend database, then each frontend shall
> > have its own full text index.
> 
> What is a "web frontend" in this context? A Host?
> 
> You are saying that "Each Midgard database shall have its own full text index".
> This is a bit of a change compared to the current situation where each logical
> site (which could be driven by more then one host) has its own index. You can
> basically configure this using the indexname configuration directive (which
> defaults to hostname:port).

Something between I think. One sitegroup in one database may use 10 different hosts
where search functionality should be reusable IMO.

 
> Right now, this'll change indexed field names. The current index is not tied to
> the MgdSchemas but to the Datamanger one's, at least in all cases where indexing
> is fully automated. The main reason for this is, that DM* will allow you to
> define your own custom additional fields and have simple names for it.
> Regardless *where* the data is actually stored. The uniqueness constraints on
> the DM field name listing makes indexing them safe in this context.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eero af Heurlin | 3 Jan 11:29
Favicon
Gravatar

Re: Following links in QB


Torben Nehmer wrote:
>>>      *    $qb = new MidgardQueryBuilder("midgard_article");
>>>      *    $subqb = $qb->forward_join("author");
>>>      *    $subqb->add_constraint("username", "=", "foo");
>>>      *    $qb->execute(); // Returns all articles authored by "foo"
> 
> 
> Why not sticking to the dot-syntax?
> 
> $qb->add_constraint("author.username", "=", "foo"); looks much easier to me and
> is equally readable.
> 

The dot syntax for simple forward joins should naturally be available as
a shorthand, but if we follow another level of link then it gets hairier.

It's also consistency, backward join practically needs the subqb and a
method to instance it, so it's good to have the forward join method as well.

/Rambo
Permalink | Reply | 0 comments |
headers
Jukka Zitting | 3 Jan 11:31
Picon
Gravatar

Re: mRFC 0024: Full text indexing in Midgard

Hi,

On 1/3/06, Torben Nehmer <torben <at> nehmer.net> wrote:
> What is a "web frontend" in this context? A Host?

A host. As in a setup where the database is located on a separate backend host.

> You are saying that "Each Midgard database shall have its own full text index".
> This is a bit of a change compared to the current situation where each logical
> site (which could be driven by more then one host) has its own index. You can
> basically configure this using the indexname configuration directive (which
> defaults to hostname:port).

The idea here is to follow the current query builder model as closely
as possible to avoid introducing extra data structures. The tree model
support is introduced to make it easy to constraint queries to just
selected parts of the content tree.

> Right now, this'll change indexed field names. The current index is not tied to
> the MgdSchemas but to the Datamanger one's, at least in all cases where indexing
> is fully automated. The main reason for this is, that DM* will allow you to
> define your own custom additional fields and have simple names for it.
> Regardless *where* the data is actually stored. The uniqueness constraints on
> the DM field name listing makes indexing them safe in this context.

I'm relying on MgdSchema as the default mechanism for specifying the
fields so I don't see a need for an additional mapping for the
parameter names. If MidCOM were to use the proposed full text index,
then I suppose the best option would be to do the name mapping at the
PHP level where you have the Datamanager schemas available.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jukka Zitting | 3 Jan 11:41
Picon
Gravatar

Re: Following links in QB

Hi,

On 1/3/06, Torben Nehmer <torben <at> nehmer.net> wrote:
> Why not sticking to the dot-syntax?

Rambo already nailed this. Keep the dot syntax for simplicity but add
the forward_join() method for more complex cases. A chained join could
for example allow me to search for all articles authored by members of
a given group. :-)

> The main problem I see here is integration with the current ACL implementation,
> which is not possible unless we start moving ACL to the core.

Good point. The QB is currently unaware of ACL in any case so adding
these methods doesn't change anything in this respect. You are right
in that by complicating the QB model this also makes it m to integrate
the ACL semantics into the core.

> The problem of course is that this is potentially a big performance hog.
>
> So we need to have an official point of view wether we a) want to enforce ACLs
> 100% or b) have a few well-defined exceptions for performance reasons.

I'd go for option a) and just document that complex joins will
probably take a performance hit from the ACLs.

BR,

Jukka Zitting
(Continue reading)

Permalink | Reply | 0 comments |

Gmane