cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [RT] A Unified Environment Model?
Date Thu, 03 Mar 2005 10:01:14 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();
> } 

Cool!

> Hmm, I can't help myself but this interface looks a little bit too 
> simple for me :)

So you have no suggestions about how to remove the remaining fat from 
the interface :)

More seriously, take a look at e.g. the FlowAttributeModule, the only 
thing it does is that it implements:

*protected* Object getContextObject(Configuration modeConf,
                                  Map objectModel)

and then the AbstractJXPathModule applies JXPath on the object and 
implements the InputModule interface above it. In the script OM case, 
the accessing is better done by script and expression languages. And in 
the method above, you took away the objectModel, and the modeConf was FS 
from the very begining, IMHO. If we just return the object we don't need 
to differ between input and output. Returning an object might seem to be 
a weak interface, but the clients to this interface are Java reflection 
mechanisms in script and expression languages and they are generally 
written to accepts POJOs.

We can certainly add optional interfaces to make the "module" 
implementations complicated enough ;) What about caching e.g. If we let 
a "module" implement CashableProcessingComponent we could let it collect 
info on what is accessed during e.g. template execution and construct a 
"delayed "validity object from that, much like what the TraxTransformer 
does for xsl:includes, IIRC.

/Daniel



Mime
View raw message