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.

Considering allowing project specific object model extensions, if we add better URI and application parameter handling to e.g. the context object, I'm satisfied with that. For project specific extensions I think flowscript will be enough especially if we make it easier to use with (flow)script actions.

But Carsten seemed to see a need for plugable object model extensions and maybe other does. Please describe your use cases so that we can discuss how to solve them.

/Daniel



Reply via email to