Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:I agree about that a configurable OM is usefull. The question is how we want to package it. We could go the module way and let all the object accessors be available in flow, template etc. Or we could go the FOM way and put a number of object accessors under a common root object, "cocoon" e.g.
Are you refering to the idea of having a configurable OM? I found it initially to be FS, but everybody else that was involved in the discussion wanted it, so I based my proposal on it. Carsten wanted it for giving access to some portal specific data for portal use whithout needing to have it everywhere else. Having a minimal OM could also make sense for making things cacheable.
In my opinion a configurable OM helps in developing web applications. Imagine you have some global settings for your application that you want to access in your pipeline, e.g. the contact email address (silly example). With a configurable OM, you can make this configuration available in flow and in your template by just configuring something in cocoon.xconf (or whereever it is). I still think it's usefull.
On the other hand, I just added some hooks to my application framework and now I'm able to do this using the framework... :)
If we follow the "FOM way" one could then have several root objects for different purposes.
I don't know what I prefer yet.
The main advantage with the "module way" is simplicity and the main disadvantage is that one have no possibility to have different things available in different contexts.
For the "FOM way" advantages are back compability with current FOM, flexibility, possibility to gather things that belongs together in one "map". A possible technical advantage is that it might be easier for e.g. a template generator and the OM to discuss caching aspects if there is a common root object that all accesses are made through.
The main disadvantage with the "FOM way" is that it migth be FS.
WDYT?
/Daniel
