> -----Original Message-----
> From: Christian Haul [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 08, 2002 9:38 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [VOTE] Input module chaining (Re: XML input module)
>
>
> On 08.Oct.2002 -- 08:13 AM, Carsten Ziegeler wrote:
> > Christian Haul wrote:
> > >
> > > On 04.Oct.2002 -- 11:07 AM, Christian Haul wrote:
> > > > On 02.Oct.2002 -- 06:38 PM, Stefano Mazzocchi wrote:
> > >
> > > > a) if JXPath should be
> > > > a1) a meta module or
> > > +0
> > > > a2) property of specific modules.
> > > +1
> > >
> > Sorry, I'm a little bit lost here. Can someone give an explanaition
> > or pointer to some use cases or examples for meta modules?
>
> Please see original thread for arguments in detail
> http://marc.theaimsgroup.com/?l=forrest-dev&m=103338039706391&w=2
> and
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103354978904793&w=2
>
> In the sources you'll find for example a DefaultsMetaModule which does
> a simplified chaining (more below) or a DigestMetaModule that does a
> secure hash on a value obtained from another module. There is a
> CollectionMetaModule that reads parameters and creates a collection
> suitable to insert into a object-relational database. ...
>
> request object -> request-param -> collection -> DatabaseAction
>
> source InputModule InputModule destination
> "Meta"
>
> > As far as I understand InputModules, the meaning of the "key"
> > to lookup a values is property of the module, so this can either
> > be a path or a single value or whatever.
> >
> > > > b) how chaining should be done
> > > > b1) as property of individual modules (i.e. through inheritance)
> > > -1 (modules may do so)
> > > > b2) as meta module (i.e. through composition)
> > > +1 (preferred method)
> > >
> > I need some examples for chaining here .
>
> See above for an example.
>
> Another, prominent one, is the case where a value is not present and
> another value should be used. This is what the original discussion was
> mostly about.
>
> Say, you provide different skins (cascading stylesheets for
> example). One could provide a default one, the user could have set one
> in his / her session or may try a new one, indicated through a request
> parameter. In addition, some operations require the design to switch
> to yet another skin, based upon the outcome of a action.
>
> So, you want to use
> 1) request attribute
> 2) request parameter
> 3) session attribute
> 4) default value
> in this priority order. The first one found should be taken.
>
> The DefaultsMetaModule does a little bit of that. Only that it allows
> to use only one source and a default value.
>
Ok, thanks for your help - sorry, I'm jumping into this a little bit
late, but I have to question this concept.
As far as I understand this, the chaining is configured in the cocoon.xconf.
Each Input Module is configured with a "default" input module in the
case it doesn't know the value for a key, right?
Now if I have two different use cases, one with the order you mention
above and one with a different order, let's say 3) - 1) - 2) - 4) how
can I achieve this?
I think if we want to have chaining this must be a little bit more
dynamic - and please, don't mention FS now :)
Now, one possibility is to provide a notation for default values (I
think we discussed this already several months ago, but I don't
remember the result...):
{request-attribute:skin:*default_value*},
Now if you want chaining, you can write:
{request-attribute:skin:{request-param:skin:*default-value*}}
and so on.
This doesn't look nice, I know - but it's only a suggestion which
is more flexible. And each input module does not know anything
about chaining.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
