cocoon-dev mailing list archives

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

> Sylvain Wallez wrote:
>> Carsten Ziegeler wrote:
>>> Daniel Fagerstrom wrote:
>>>> So the innocent looking i/o modules give us a quite a number of 
>>>> problems if we want to build an OM from them.
>>> Yes, I agree.
>>>> So what do I propose instead? If we think of it the only thing we 
>>>> need is access to objects (and preferably script (SL) and 
>>>> expression language (EL) friendly objects). Then it is the task for 
>>>> the EL or SL to do the accessing. If the object is read or write 
>>>> able or booth will be seen from its get and/or set methods or 
>>>> whatever the reflection engine in the EL or SL supports.
>>>> So instead of i/o modules it would be enough with "modules", (but 
>>>> we should really find a better name). And the interface could look 
>>>> like:
>>>> interface Module {
>>>>   String ROLE = Module.class.getName();
>>>>   Object getObject(Map objectModel);
>>>> }
>>>> thats all. So much simpler than i/o modules and we get better 
>>>> behaviour and SoC at the same time.
>>>> WDYT?
>>> Sounds like a good solution for me. Now, these "modules" will be 
>>> Avalon components, so I think we should remove the objectModel 
>>> parameter from the interface. (An avalon component can get the 
>>> object model if it's contextualizable) This simplifies the interface 
>>> even more and makes calling it easier:
>>> interface Module {
>>>   String ROLE = Module.class.getName();
>>>    Object getObject();
>>> }
>> Sorry, I should have missed something. What is the purpose of a 
>> service interface that just returns an object. Why isn't this object 
>> the component itself? Just like the current OM contains the request 
>> and response objects, and not proxy components that give us access to 
>> request and response. 
> The purpose was mainly to not put any requirements on the _returned_ 
> object, like implementing serviceable or contextuable etc, and also 
> avoiding to exposing these interface to the user.

That is the Module itself that is a component and therefore can be 
serviceable etc. Not the returned object.

> But that is a tradeof, maybe it is better to let the component be the 
> object itself.

Nono, I've understood now (see my answer to Carsten).

>> Furthermore, how are the module attributes accessed? Does this become 
>> the responsibility of the EL in which the module is used?
> Yes, the idea is that the EL or scripting language is responsible for 
> access.
>> Isn't it too restrictive compared to the variety of what modules do?
> 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 at 
the price of a reduced readability...

>> Or it will require us writing a lot of Scriptable implementations to 
>> expose attributes as dynamic properties.
> Yes, my idea was to package the script OM from FOM as "modules". But 
> if we can find an interface that gives the EL and script 
> implementation more help, that would be better.
>> What about a AttributeHolder interface:
>> interface AttributeHolder {
>>  Object getAttribute(String name);
>>  void setAttribute(String name, Object value);
>>  void removeAttribute(String name);
>>  Enumeration getAttributeNames();
>> }
>> This interface gathers both input and output features which solves 
>> the current duality between input and output modules. Input-only 
>> modules can simply throw a UnsupportedOperationException on set and 
>> remove.
>> This interface can eventually also be applied to a number of other 
>> objects such as Request, Session and Context (the env one), CForms 
>> widgets, etc that all already have these methods.
>> Thoughts?
> 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.

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


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message