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.
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?
Yes :)
e.g. I like to use chained input modules (i18n issues) or my own constants input modules.Hmm, the question is: how can a pluggable object model work - or how can it be extended? What about using...input modules for exactly this? We create a way of "mounting" input modules into the object model, like this:
<object-model>
<mount input-module="skin" path="cocoon.skin"/>
</object-model>
And then you can simple access the info by ${cocoon.skin.something}.Carsten
