cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Piroumian Konstantin <>
Subject RE: Chaining order (Re: [VOTE] Input module chaining)
Date Thu, 10 Oct 2002 10:23:20 GMT
> From: Stefano Mazzocchi [] 
> Piroumian Konstantin wrote:
> >>
> >>>>So the user would say {default:skin}, and get the 'skin' request 
> >>>>parameter, or if not present, 'defaultSkin'.
> >>>>
> >>>>IMO this is backwards. The user should use {request:skin}, not 
> >>>>{defaults:skin}.
> >>>>
> >>>>What do people think? Chris?
> >>>
> >>>I imagine this a little different, e.g.:
> >>>
> >>> <component-instance
> >>>class="org.apache.cocoon.components.modules.input.SkinModule"
> >>>         logger="core.modules.input" name="skin">
> >>>   <input-module name="request-param"/>
> >>>   <input-module name="skin-defaults"/>
> >>> </component-instance>
> >>
> >>Oo.. that's a good idea. Say we've got all these modules
> >>floating about loose, and then we have a 'glue' module that 
> >>can stick together a bunch of them.
> > 
> > 
> > Exactly this I've been trying to say all this time. Seems that it's 
> > time to went to some English courses ;)
> > 
> > 
> >><component-instance class="...GlueModule" name="forwards">
> >>  <input-module name="A"/>
> >>  <input-module name="B"/>
> >>  <input-module name="C"/>
> >></component-instance>
> >>
> >><component-instance class="...GlueModule" name="backwards">
> >>  <input-module name="C"/>
> >>  <input-module name="B"/>
> >>  <input-module name="A"/>
> >></component-instance>
> > 
> > 
> > Exactly!
> Sorry but I totally lost you people and I have the impression 
> that many 
> round here have the same problem (look at Carsten that woke 
> up only very 
> recently on this input-module thing :-P
> Hey, remember we are supposed to be anti-FS knights, ok? :)

Ok. I'll give a real Use-Case and you look at it with your critical glance.
Maybe we are too input-module-minded after so many discussions and are

Forrest's Use-Case

Forrest has skinning system which now uses Ant filtering tokens in the
sitemap to define which skin to use, e.g.:

<map:transform src="skins/@skin@/style.xsl" />

Everyone agrees that this looks ugly and the skin name is hard-coded in the
resulting sitemap, which makes it impossible to change the skin at runtime
in the web-app version of Forrest. It also requires the source to be copied
to the 'build' directory and makes development a little more difficult (you
should run build after every change in the sitemap, while Cocoon could
reload it from the source directly).

Using a special input module makes sitemap look much better:

<map:transform src="skins/{skin:name}/style.xsl" />

Everyone agrees with this one too.

Where does the skin module get the configuration data? There are several
places where it can get it:
	- a request parameter (?skin-name=forrest-site)
	- a session attribute (after the user has set this somewhere else)
	- a cookie (to retain user's settings between sessions)
	- a config file (customized default values for a specific project)
	- configuration in cocoon.xconf (global default, used if customized
config is not found)

So having already input modules for 'request-param', 'session-attr',
'cookie' and 'xml-config' we can use a meta module which simply traverse
it's child input modules and tries to get the value from them. Then it was
proposed this approach:

<component-instance class="MetaModule" name="skin">
	<input-module name="request-param"/>
	<input-module name="session-attr"/>
	<input-module name="cookie"/>
	<input-module name="xml-config"/>
	<input-module name="defaults"/>	

> So, what the heck is this 'glue' thing?

So, the 'glue' is a meta module which has other input modules as its config.

> And why is Torsten is talking about "filters"? gosh, don't you people 
> think we already have enough concepts and components and models and 
> names? (expecially when they are so widely used that nobody 
> really knows 
> if the user already knows the concept or has to relearn it 
> from scratch)

I have no idea what the 'filter' can mean in this context, but from the
user's point of view, input modules act as namespaced sitemap variables,

<map:transform src="{request-param:stylesheet-name}.xsl" />

So, instead of using a wrapper action to get a request parameter value in
the sitemap, the user will simply use this short version.

> Sorry for playing devil's advocate, but that's my 
> self-inflicted role, 
> you know? :)

We definitely need some critics.


> -- 
> Stefano Mazzocchi                               <>
> --------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

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

View raw message