cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: [RT] A Unified Environment Model?
Date Thu, 03 Mar 2005 10:16:22 GMT
Daniel Fagerstrom wrote:
> Carsten Ziegeler wrote:
>>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.
Yes, yes, that's why I think that your suggestion is the way to go, too.

> 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.
Ok, ehm, let's start with the simple interface :) All we need is a
better name...


Carsten Ziegeler - Open Source Group, S&N AG

View raw message