cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: [SUMMARY] input module chaining
Date Wed, 09 Oct 2002 06:54:06 GMT
Thanks Jeff for this summary!

Jeff Turner wrote:
> At Carsten's request, I'm attempting to summarise a long (46 email)
> thread about input module 'chaining'. See [1] for exactly which mails I
> mean. Re-reading it, it seems I'm the only one who was really
> confused, but
> here's a summary anyway.
> For the record: input modules are classes which give you easy sitemap
> access to various kinds of data, most commonly the HTTP request data. For
> examples, see src/webapp/samples/modules/sitemap.xmap. The data model is
> "keys to values", similar to a Properties object. So {moduleA:foo} means
> "look up the value corresponding to the key 'foo' in the 'moduleA'
> module."
Ok, I think the first sentence here is one central point of problem:
Currently I (and it seems others as well) see input modules only as
to be used in the sitemap.
I think Christian had a much wider intention for this concept.
If we use InputModule primary in the sitemap than this is a "special"
Cocoon concept - if this has a much wider sense than InputModules should
be more general and shouldn't be developed inside Cocoon but
for example Excalibur or Commons etc.
That's the reason why I didn't answer the question where OutputModules
or the third one should go - I think all of this does not directly
belong to Cocoon because it has a more general approach.


> As Carsten summarized, the thread has covered two types of inter-module
> behaviour, both called 'chaining' at various stages:
> a) "Defaulting". Where if a module doesn't contain a value, another
>    module is queried. Primary use-case for Forrest.
> b) "Real chaining". Where a module uses another module's input to decide
>    it's output. Examples include DigestMetaModule, which "obtains values
>    from other module and returns message digest of value".
> Not making this difference clear has led to _lots_ of confusion. But on
> with the summary..
> About 10 days ago, I submitted an XMLModule[2], which allows
> XPath access to an
> XML file, inside a sitemap (eg {configfile:/foo/bar}). Chris said:
>   "I would prefer that module to be a "meta" module that can be
>   configured to take input from any source (i.e. another InputModule)
>   rather than do the reading itself."
> Here, Chris was trying to broaden the use of "real chaining". However,
> "real chaining" doesn't particularly make sense to XMLModule. I said
> this, and then introduced the "defaulting" pattern of use:
> > Often, one wants a variable's value to come from one of a number of
> > sources, ordered by preference:
> >
> >  - From a request value, or if not present,
> >  - From a session value, or if not present,
> >  - From an XML config file or database.
> To which Chris replied:
> > To this I would suggest to have a module that does exactly this, along
> > the lines of the current DefaultsMetaModule. Just that it takes a
> > configurable list of modules to test. I hope that it's still not FS ;-)
> It's a pity I didn't understand the distinction between "defaulting" and
> "chaining", and that they should be solved individually. To cut a looong
> story short, we ended up agreeing[3] on a solution to the "defaulting"
> problem:
> Simple use-case: say we want to know the site 'skin' in the
> sitemap, in order to
> know what stylesheets to apply. The skin may be determined, in order of
> preference:
>  - a request parameter, OR (if not present)
>  - an XML config file for the site, OR (if not present)
>  - a default value
> So first, one would declare the individual modules:
> <component-instance
> class="org.apache.cocoon.components.modules.input.RequestParameterModule"
> logger="core.modules.input" name="request-param"/>
> <component-instance
> class="org.apache.cocoon.components.modules.input.XMLModule"
> logger="core.modules.input" name="xmlconf">
>   <config>resource:///forrestconf.xml</config>
> </component-instance>
> <component-instance
> class="org.apache.cocoon.components.modules.input.DefaultsModule"
> logger="core.modules.input" name="default">
>   <values>
>     <skin>defaultSkin</skin>
>   </values>
> </component-instance>
> So far, {default:skin} returns 'defaultSkin', {xmlconf:/*/skin} returns
> 'forrest-site' and {request-param:skin} returns whatever.
> Now we declare a 'chaining' module which implements the
> if-then-else behaviour
> described above:
>  <component-instance
> class="org.apache.cocoon.components.modules.input.ChainingMetaModule"
> logger="core.modules.input" name="skin">
>    <input-module name="request-param"/>
>    <input-module name="xmlconf"/>
>    <input-module name="default"/>
>  </component-instance>
> The implementation of this is very simple: query each configured
> module in turn,
> until one returns a value.
> Pretty obvious really :) You have to look at the current
> DefaultsMetaModule
> usage to appreciate just how much simpler than the current system this is.
> Also, please note that this defaulting system can be implemented
> with almost any
> underlying input module API.
> --Jeff
> [1] The thread starts at:
> and
> It incorporates mails with subjects like:
> XML input module (was: RE: Nice changes!)
> Input module chaining (Re: XML input module)
> [VOTE] Input module chaining (Re: XML input module)
> Chaining order (Re: [VOTE] Input module chaining)
> [2]
> [3]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

To unsubscribe, e-mail:
For additional commands, email:

View raw message