cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject [RT] A Unified Environment Model?
Date Mon, 28 Feb 2005 22:48:34 GMT
As discussed in various threads we need a common environment model for 
flow, templating (both with flow and non-flow input). And it will also 
make Cocoon easier to learn if the environment part of FOM (let us call 
it OM) and the sitemap environment model, i.e. input modules (IMs) are 
put together in some way.

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

Mime
View raw message