cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <>
Subject Re: Status of JXTemplate refactoring
Date Fri, 09 Sep 2005 20:17:23 GMT
Daniel Fagerstrom wrote:
> Second, it is somewhat over componentisized for my taste: Does the 
> default instruction factory really be a component? Wouldn't be enough to 
> give it an URL to the script configuration in its constructor. 
Thing is the instruction factory instantiation can be a little bit 
heavy. The Instructions' constructors are looked up using reflection and 
cached. Right now this is done once per cocoon instance (thread safe). 
The way you propose it every jxtg instance would have to repeat those 
steps which wouldn't be a good idea (think how much processing would be 
needed to instantiate another jxtg instance in case the pool was empty).

> Same 
> thing with the DefaultScriptManager, if you give it a name space, and a 
> parser to its constructor, there is not that much need to make it a 
> component. The parser could in turn be given an instruction factory and 
> an JXTExpressionCompiler as arguments to its constructor.

public void service(ServiceManager manager) throws ServiceException {
     this.manager = manager; = (Store) this.manager.lookup(Store.TRANSIENT_STORE);
     this.instructionFactory = (InstructionFactory) 
     this.jxtExpressionCompiler = (JXTExpressionCompiler) 

public void dispose() {

We gain little, we lower the readability of JXTGenerator itself exposing 
what the implementation ScriptManager is made of. After all: if it's 
composed of 3 external beans it's a good candidate for a component (I 
might not think straight after using Spring too much lately :))

> In the end I think it will be simplest if the generator looks up the 
> plugable components and the configuration files, i.e. the 
> JXTExpressionCompiler and the instruction configuration file and maybe 
> some more stuff and just pass these components to the other classes in 
> the template framework.
The last one: StringTemplateCompiler. If we are to unify expression 
handling in whole cocoon it should be a component anyway.

> The most natural thing would be to have a generic template generator 
> that you just configure with what instuctions and what expression 
> compiler you want. But people didn't want that level of flexibility so 
> therefore such things need to be hard coded in the generator class.
> In general, the main use for components is if one really know that one 
> will need to be able to choose between several different implementations 
> of the same interface at deploy time. And if one want to be able to use 
> several implementations of the same interface at once in a plugable way, 
> selectors is the way to go. Otherwise components are overkill.
Components are also a good thing if:
1. They are thread safe and creating them is somewhat costly
2. They reference a lot of other already componentized logic.

>> I assume we want to keep backward functionality.
> Yes!
>> Is it OK if I just create CTemplateGenerator extending current 
>> JXTemplateGenerator?
> Better, create a common AbstractTemplateGenerator and let both 
> JXTemplateGenerator and CTemplateGenerator extend it.
I hope I'll finish the refactoring this weekend.

Leszek Gawron                            
IT 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