cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: FOM & input modules
Date Mon, 24 Jan 2005 21:46:05 GMT
Daniel Fagerstrom wrote:
> 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.

good idea! I haven't thought much about this yet, but I think you're right. (I 
was just a user who found a solution for this problem :-) )

> 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.

After some experiments with the new compiling classloader stuff, I personally 
don't feel a need for a scripting action solution. But this highly depends on 
your skills.

> 
> 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.

ok, sounds reasonable

> 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 ;)

-- 
Reinhard

Mime
View raw message