cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] A Unified Environment Model?
Date Thu, 03 Mar 2005 14:50:38 GMT
Sylvain Wallez wrote:

> Daniel Fagerstrom wrote:
>> Sylvain Wallez wrote:

>> Don't think so (returning an Object does not to restrict things that 
>> much ;) ), but I haven't thought in detail about all modules, any 
>> examples where it wouldn't work?
> E.g. those modules that do some xpath extraction on XML data. But 
> maybe that isn't a problem if we consider my JS-as-the-only-EL 
> proposal as we could write 'xpath(om.xmlmodule, "/path/to/element[1]")'.
> Not as readable as 'xmlmodule:/path/to/element[1]' but well, it makes 
> it possible to delegate all expression handling to the surrounding 
> context rather than leaving the possibility for each module to invent 
> its own. This apparent constraint actually leads to an enforced 
> consistency

Yes, enforced consistency is an important point.

> at the price of a reduced readability... 

Doesn't have to be that way. In your 'xmlmodule:/path/to/element[1]' 
example, the "module" is only responsible for returning an XML object (a 
DOM e.g.), i.e. the 'xmodule' part of the string, then it is the task of 
the surrounding context to decide what it want to do with the object. 
For sitemap usage that would be to use the second part of the string 
'/path/to/element[1]' as expression through the default sitemap EL, 
which could be JS or JXPath depending on taste, community decision, 
sitemap version etc. I would prefer to use the pluggable expressions 
from template for this.

In the flow context we would have something like cocoon.xmodule instead 
and we would use relevant Rhino mechanisms for accessing the DOM (or 
maybe the XMLBean), and this could be done through E4X or some JXPath 


>> The important thing for the "modules" is to provide script friendly 
>> access of environment data in a simple way. I assumed that the 
>> easiest way would be to support "POJO" interfaces with get and set 
>> methods and Maps so that it would be easy to use for the reflection 
>> parts of ELs and scripting languages, but I don't know that much 
>> about it. If an AttributeHolder is a better anwer to those 
>> requirements we should take that route instead.
> Well, AttributeHolder allows each Module to define his own syntax for 
> accessing properties, which may not be what I want. 

The same holds for Java Maps, and I doubt that people have been so 
creative so that they send XPaths as name ;) It is more that we IMO get 
better SoC if the context is responsible for accessing the content of a 

> And if we (again) consider JS-as-the-only-EL, this can be replaced by 
> Rhino's Scriptable interface.

As I wrote in another mail we can use Scriptable for the scriptable OM, 
whithout the "JS-as-the-only-EL"  strategy as we allready, AFAIU, have 
mechanisms for accessing Scriptables from Jexl and JXPath that are used 
in JXTG. Again I think it is an intresting idea to focus on JS as EL, 
but I still want to hide the use of JS as EL behind an interface to 
simplify migration and back compability and also to enforece better SoC 
in the core.


View raw message