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
