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.
WDYT?
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 http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111329909419717&w=2
- introduce pluggable convertors
what more?
We discussed it in http://marc.theaimsgroup.com/?t=110942300500004&r=1&w=2.
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.
/Daniel
