cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: FOM & input modules
Date Mon, 24 Jan 2005 18:44:37 GMT
Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
>> Reinhard Poetz wrote:
>>> Daniel Fagerstrom wrote:
>>>>
>>>> Please note that I'm not suggesting to remove the current input 
>>>> modules. This is all about making Cocoon more coherent, not about 
>>>> introducing back incompability. If we find a good way to replace 
>>>> input modules I would suggest that we move them from core to an 
>>>> input module block so that they become optional.
>>>>
>>>> WDYT?
>>>
>>> Having only one input module that uses a Cocoon wide object model is 
>>> IMO a good idea. We should go through the list of all input modules 
>>> and look where it makes sense to extend the object model.
>>
>> I wrote the slightly commented list of  input modules that you cutted 
>> away from my post in the hope of geting some input about that. I use 
>> modules that overlaps with FOM in nearly all of my sitemaps so I don't 
>> have much opinion about the more exotic modules.
>>
>> The things that I need that not is part of FOM is some type of 
>> handling of global or sitemap specific data corresponding to e.g., 
>> DefaultsModule or GlobalInputModule. But it is rather the handling of 
>> application parameters than the actual input module solution that I need.
>>
>> Also I have used the BaseLinkModule and some own module for URL 
>> rewriting purposes.
>>
>> Both application parameters and better sitemap related URL handling 
>> could be part of the Context object IMO.
>>
>>> Creating a modules block that contains all existing input modules for 
>>> backwards-compatibility sounds good to me too.
>>>
>>> One question remains: Should it be allowed to add your 
>>> project-specific extenstions to the object model? e.g. I like to use 
>>> chained input modules (i18n issues) or my own constants input modules.
>>
>>
>>
>> Could you explain your use case a little bit more.
> 
> 
> Something like this:
> <component-instance name="l"
>    class="org.apache.cocoon.components.modules.input.ChainMetaModule"
>    logger="core.modules.input">
>  <!-- first try the 'locale' request param -->
>  <input-module name="request-param"/>
>  <!-- next the session attribute -->
>  <input-module name="session-attr"/>
>  <!-- next try the request locale attribute -->
>  <input-module name="request-language"/>
>  <!-- finally use a default value -->
>  <input-module name="settings"/>
> </component-instance>
> 
> This is useful to determine the language of my application but needs to 
> be configurable. Don't know if such a chain module should be part of the 
> object model, but why not.

Why not? Because chain modules and the rest of the meta modules IMO 
sucks from readability POV. Without the comments the above snippet would 
have said nothing to me. I would guess that if you had written the above 
code in terms of flowscript it would have been much easier to see what 
happens.

If you need the above i18n stuff in all your pipelines you could just 
call a (flow)script action without any match criterion in the begining 
of your pipeline and let it calculate the locale and put it in a context 
variable where it is visible in the rest of the pipelines.

To me that is less magic than having a XML based semi program language 
in your configuration.

The original idea with input modules, giving pluggable access to 
environment properties was a good idea IMO. Even if the inteface with 
all the configuration parameters smells FS to me. But then a small 
program language is build on top of that in terms of the meta modules 
with more or less obscure programming constructs.

IMO we should try to give this a fresh look and try to get rid of the 
need to use meta modules. So I don't feel any entusiasm for pluggin in 
modules in the object model.

 From the discussion this far my conclusion is that we need to 
strengthen the context model with same kind of application global 
parameters, better info for URL rewriting and also that we need 
(flow)script actions for an easy way to put application specific data in 
the object model.

But I have not yet seen any use cases that convinces me about the 
necesity in pluging input modules into the object model.

Maybe our anti FS task force have some wise words to add ;)

/Daniel

Mime
View raw message