The requirements on accessing the environment seem to me very similar in sitemap, flow and templates. The main difference is that sitemap and template are input only while flow is i/o. Also there is not that much data isolation between sitemap, flow and templates. The sitemap can export IM content to flow and templates (though only as strings) through sitemap component params. And flow can export to sitemap and templates through the flow context (and flow context module).
In spite of the large similarities the OM and the IMs are designed along rather different design philosophies.
Let us compare them along some different concern dimensions:
Flexibility -----------
IMs are extremely flexible, the user can add own as they like, they are configurable, they can interpret their "value" string as they want to, they can be put together in various ways and they have acess both to the object model and to the service manager.
OM is designed along a less is more philosophy and it is dependent on community decisions what it should contain.
Easy of Use -----------
OM is slightly easier to use as it is configured once and for all in code and always is available in flow and JXTG.
But even if IMs are more complicated to configure, Cocoon is delivered with preconfigured standard IMs so in practice they are as easy to use.
Script Awareness ----------------
OM have JS wrappers that also are used for expression language (EL) access. IM has not. If script awerness is an advantage or not and how it should be achieved have been discussed in other threads ;)
SoC ---
OM has the clear focus on embeding the environment (especially if we follow Sylvains proposal http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110672768112495&w=2 and factor out the flowscript related functions).
IM embeds environment, apply expressions on it, can be aplied on each other and even combine IMs in some kind of cases statements in terms of cascade modules.
API ---
OM is a Map. IMs are like maps but have both construction and runtime configurations and also interpret the "key" in much more sofisticated ways than maps normally do.
Cache Friendliness ------------------
OM is rather cache unfriendly (in template use) as it can be a rather large chunk of data that always is available in JXTG. "Pragmas" in the template are needed to steer caching. Automatic caching seem not to be feasable.
As caching is a pipeline rather than a sitemap concern, cache friendlines isn't relevant for IMs. But it is instructive to study the environment handling for the TraxTransformer. As default it only has sitemap parameters available and they are used in the cache key. By suplying e.g. IMs as sitemap parameters one get automatic caching (at the cost of declaring the input).
--- o0o ---
Ok, how do we combine the best properties from OM and IM so that we can use the same concept everywhere? This was discussed in http://marc.theaimsgroup.com/?t=110654827400001&r=1&w=2 and http://marc.theaimsgroup.com/?t=110672768200001&r=1&w=2.
Focus on OM -----------
One approach is to focus on the development on OM. Then we evaluate the input modules and we lack something important in OM and add it. Then we can create an OM module that uses a plugable expression from template on the OM. This OM module could then be used in the sitemap and replace all the IMs.
Make OM Pluggable -----------------
A much more popular option seem to be to make OM plugable. Carsten proposed how it could be configurated, http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110657224222559&w=2.
Just plugging in the existing IMs in the existing OM seem rather clumsy according to my (puristic) taste. I would propose:
* All content in OM are plugged in IMs.
* We create new IMs from the request, session etc embedings in OM. In this way we keep the script awareness. As everything is configuration based there is no problem to keep the current environment IMs for those who want back compability.
* The new IMs doesn't contain own expression handling anymore, this is solved through a common external mechanism that uses the new plugable expressions (don't know how to achieve this though).
* Move out the current IMs to an own block.
I think such a solution would combine the best aspects of OM and IMs.
* It certainly breaks the "less is more" approache from OM. But we can at least apply that priciple in our choice of "core" IMs and in our docu. Then more advanced users can have the freedom to shoot them selves in theire foot if they feel like.
* It keeps the script friendliness from OM.
* By separating the EL mechanism from IMs (if we can find out how), and removing meta modules from core. We focus on a solution with better SoC.
* We could discussing a more focused API for modules (a Map), but I doubt that it is worthwhile.
Configuration -------------
Now the question is how should the OM be configurated. Should we have a global configuration or should it be configurable separatly for each use in the sitemap?
Probably booth. We could have a global OM configuration for JXTG and flow as we have (implicitely) today for ease of use. Then more advanced user can configure their template generator in more detail according to their needs. In some applications it might be a good idea to have an empty OM for the template and insert all environment input through sitemap params, for such use one use "automatic" cache key calculation.
--- o0o ---
Of course we should keep the current mechanisms for back compability. For IMs there is not much of a problem as they are configurable anyway. We can just move such IMs where there are "better" ways to achieve its function, to a separate block.
For OM it shouldn't be that hard to keep back compability either, we could package it as an IM e.g.
WDYT?
/Daniel
