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 11:14:17 GMT
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.

Furthermore, how are the module attributes accessed? Does this become 
the responsibility of the EL in which the module is used? Isn't it too 
restrictive compared to the variety of what modules do? Or it will 
require us writing a lot of Scriptable implementations to expose 
attributes as dynamic properties.

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.



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

View raw message