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.
Hmm:
public void service(ServiceManager manager) throws ServiceException {
this.manager = manager;
this.store = (Store) this.manager.lookup(Store.TRANSIENT_STORE);
this.instructionFactory = (InstructionFactory)
this.manager.lookup(InstructionFactory.ROLE);
this.jxtExpressionCompiler = (JXTExpressionCompiler)
this.manager.lookup(JXTExpressionCompiler.ROLE);
}
public void dispose() {
this.manager.release(this.store);
this.manager.release(this.instructionFactory);
this.manager.release(this.jxtExpressionCompiler);
}
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 [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
