> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
> 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
FS-infected.
Forrest's Use-Case
==============
Prerequisites
---------------------
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).
Solution
-------------
Using a special input module makes sitemap look much better:
<map:transform src="skins/{skin:name}/style.xsl" />
Everyone agrees with this one too.
Chaining
-------------
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"/>
</component-instance>
> 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,
e.g.:
<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.
Konstantin
>
> --
> Stefano Mazzocchi <[EMAIL PROTECTED]>
> --------------------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
