cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <>
Subject Re: [RFC] JXTG Refactoring
Date Fri, 10 Dec 2004 21:39:02 GMT
Daniel Fagerstrom wrote:
> Leszek Gawron wrote:
> <snip/>
>> I have commited an initial JXTemplateGenerator to 
>> o.a.c.template.jxtg.JXTemplateGenerator and moved Jonas' templating 
>> proposal to o.a.c.template.v2 package.
>> Please review. 
> Nice!
> Don't have time to review in any detail right now. I added some basic 
> test cases. Two of them that tries to test that the cocoon object is 
> accesible from expressions are faulty, I didn't get them to work even 
> with the original JXTG, any idea about what goes wrong?
I will look into that as soon as I finish my post.
I also have a feeling that something got wrong with jexl/jxpath leniency 

>                                   ---  o0o ---
> For further refactoring I think that we should try to factor out the 
> execute method as you certainly have seen it is quite intermingled with 
> other stuff. IMO it should be static (or better moved to an own class), 
> and depend of three arguments:
> execute(XMLConsumer consumer, ExecutionContext context, ...)
> where ExecutionContext is a new class containing the jexl and jxpath 
> contexts, ServiceManager (and SourceResolver but that is accesible from 
> ServiceManager), Variables, cache and definitions. There was some 
> discussion about context in 
It should be quite easy IMO as it's mainly moving stuff around.

> In a next step the cache object should be factored out from the 
> ExecutionContext and replaced by some kind of script manager, so that we 
> can have the code that compiles and caches the scripts at one place.
> Then execute takes a number of events as arguments, I would like to 
> abstact the coupling between execution and event implementation, but how 
> it should be done requires more thinking.
I think the approach Jonas introduced could be used. Still it needs some 
extra features (like jx:parameter or jx:evalBody handling). We need a 
lot of regression tests to do that right I suppose.

> Each tag has code in three places: its start tag that contains data, in 
> the parser for setting it up and inexecute for executing it. That is 
> rather confusing, so we shoud put all the three parts in one class. How 
> this can be done has been discussed in the above thread among other places.
> Hiding the jxpath and jexl specifc code beyond one interface would also 
> be nice.
There is JXTExpression class. If we are not planning to implement 
pluggable ELs the only thing we have to do is to create JXTContext that 
would join jextContext and jxpathContext.

Leszek Gawron                            
Project Manager                                    MobileBox sp. z o.o.
+48 (61) 855 06 67                    
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

View raw message