cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: FOM & input modules
Date Mon, 24 Jan 2005 15:19:48 GMT
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"
  <!-- 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"/>

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.


View raw message