cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: JXTG further development
Date Wed, 13 Apr 2005 14:18:57 GMT
Leszek Gawron wrote:

> The JXTG refactoring is somewhat stalled. I have no time lately to do 
> serious coding and Daniel went into more complicated things.

I will certainly get back to Templates. What happened was that some of 
the Template work was more about general infrastructure things like 
environment handling. After having studied the internals of Cocoon for 
some while I started to feel that I could do something about VPCs and 
block management. And as these areas seemed more important for Cocoon 
right now I decided to focus there instead.

>   I'd like to discuss the development scenario and list what's left.
> Some threads ago we have agreed that JXTG should be replaced with it's 
> refactored version ASAP.
> We could do it in 2.2 even now.

Yes, I'll start a vote about it.

> We'll see fast what incompatibilities were introduced and fix them.
> Second thing is further development that is totally backward 
> incompatible. What course of action do we take? Daniel suggested we 
> should clone the code now making current state the official JXTG and 
> develop new features in a separate code.

I hope I didn't sugest cloning anything, I really hate cloning code ;) 
The template processor is IIRC very close to the point where we can 
configure what instructions that are available from a configuration file 
(which is part of the code and loaded though the resource protocol). 
When this is possible we can have a AbstractTemplate class that contains 
most of the current refactored JXTemplateGenerator code. Then we can 
extend it to a JXTG that loads the instructions we have today and that 
we keep back compatible, and a CTemplateGenerator (or what we chose to 
call it), where we can add new things: new instructions, pluggable 
expression languages, better expression syntax, pluggable convertors and 
a pluggable object model.

> Things left to implement we know of:
> - refactoring of template parser. I do not quite get what we will gain
>   here. Daniel could you make some comments about how should it look
>   like - I do not know where to start from because I have no idea of
>   what I want to achieve here.

The only thing that could be usable right now is to remove the list of 
instructions (the registerInstruction stuff) from the parser and load it 
from an external configuration file. Then we need to do some more things 
to support attribute template languages, but that could wait until we 
actually do that.

> - introduce jx:attribute
> - make jx:import evaluated while parsing and not at runtime.
> - fix jx:import bug 
> - introduce pluggable convertors
> what more?

We discussed it in

> Looks like I might have more time next weeks so it's important for me 
> to have your opinion now.

Great, I try to spend some time on Templates also, so I at least can 
take part in discussions.


View raw message