Carsten Ziegeler 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.
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}.
Thats ok for me. Any ideas about how to implement it? Right now the we have the FlowObjectModelHelper that just take an object model and creates a ExpressionContext (as you implemented most of it you already know this ;) ). I guess we should make the $cocoon part of the template object model a component so that we can configure it and don't have to create it from scratch for each use of it. But at the same time it must depend on the current object model. Any ideas about how to do that?
/Daniel
