You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jeff Turner <je...@apache.org> on 2002/10/08 19:14:14 UTC
[SUMMARY] input module chaining
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."
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:
http://marc.theaimsgroup.com/?t=103338042200004&r=1&w=2 and
http://marc.theaimsgroup.com/?t=103354993700001&r=1&w=2
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] http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13131
[3] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103407750307375&w=2
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [SUMMARY] input module chaining
Posted by Jeff Turner <je...@apache.org>.
On Wed, Oct 09, 2002 at 06:55:19PM +0200, Christian Haul wrote:
> On 09.Oct.2002 -- 08:54 AM, Carsten Ziegeler wrote:
> > 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
> > components 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.
>
> Carsten, sorry for answering late.
> OK, so what further course of action would you suggest? Post a
> description to avalon-dev and ask for an opinion?
It would be interesting to hear the sales-pitch for modules outside the
scope of Cocoon. What (other than Cocoon) would ever use them, when
there's a much more popular java.util.Map interface available?
--Jeff
> Chris.
> --
> C h r i s t i a n H a u l
> haul@informatik.tu-darmstadt.de
> fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [SUMMARY] input module chaining
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Christian Haul wrote:
>
>
> On 09.Oct.2002 -- 08:54 AM, Carsten Ziegeler wrote:
> > 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
> > components
> > 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.
>
> Carsten, sorry for answering late.
> OK, so what further course of action would you suggest? Post a
> description to avalon-dev and ask for an opinion?
>
I think we (= Cocoon community) should clarify our opinion about this first.
This includes:
- Do we have a simple Sitemap InputModule Component?
- Are the current InputModule and OutputModules of a more general approach
and do we want to donate it?
If we agree on this, then the next step would be to involve the avalon
community.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [SUMMARY] input module chaining
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 09.Oct.2002 -- 08:54 AM, Carsten Ziegeler wrote:
> 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
> components
> 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.
Carsten, sorry for answering late.
OK, so what further course of action would you suggest? Post a
description to avalon-dev and ask for an opinion?
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [SUMMARY] input module chaining
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
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
components
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.
Carsten
> 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:
> http://marc.theaimsgroup.com/?t=103338042200004&r=1&w=2 and
> http://marc.theaimsgroup.com/?t=103354993700001&r=1&w=2
>
> 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] http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13131
> [3] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103407750307375&w=2
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org