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 -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
