Stefano Mazzocchi wrote:
> Piroumian Konstantin wrote:
>
>> 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.
>
>
> Thanks, I really needed that.
>
>> 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.
>
>
> Ok, cool, I see.
>
>> 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)
>
>
> Ok, got it.
>
>> 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.
>
>
> Gotcha.
>
>>
>>> 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.
>
>
> All right, finally I got the picture. I really needed that (and I
> think many others as well).
>
> Now, follow me:
>
> 1) from the user's point of view, input modules act as namespaced
> sitemap variables (you said that)
>
> 2) that means that just like the user knows that type="xslt" will
> match the transformer associated with 'xslt', the variable
> {request:skin} will match the 'skin' attribute in the input module
> named 'request'
>
> so, question:
>
> why aren't you declaring them in the sitemap?
>
> also
>
> why not calling them something more specific than InputModules?
>
> Take a look at this
>
> <map:sitemap>
> <map:components>
> ...
> <map:expanders>
> <map:expander name="A" src="..."/>
> <map:expander name="B" src="..."/>
> </map:expanders>
> ...
> </map:components>
+1 ! This should be as easy as adding a few lines in
treeprocessor-builtins.xml !
> <map:expanders-sets>
> <map:expander-set name="blah">
> <map:expand type="A"/>
> <map:expand type="B"/>
> </map:expander-set>
> </map:expander-sets>
I see the analogy with action sets, but don't think it is applicable
here. Actions are called using <map:act type="..."> whereas action-sets
are called using <map:act set="...">.
We don't have such a distinction for the use of input modules (or
yet-another-puking-syntax ?), so we steel need the meta-module, but now
declared in the <map:expanders> section.
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
