JXTG further development

[Leszek Gawron <lg...@mobilebox.pl>]

The JXTG refactoring is somewhat stalled. I have no time lately to do 
serious coding and Daniel went into more complicated things.  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. 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?

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.
- 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?

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

-- 
Leszek Gawron                                      lgawron@mobilebox.pl
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

Re: JXTG further development

[Leszek Gawron <lg...@apache.org>]

Leszek Gawron wrote:
> - make jx:import evaluated while parsing and not at runtime.
After reviewing the code I think there is no need for that.

This is the current procedure:
Parsing:
1. Store expression that will resolve to script uri at runtime

Execution:
2. Resolve script uri value
3. Get script from script manager
    a) lookup from cache
    b) if not in cache
       - resolve uri source
       - parse
       - store in cache


The only thing we skip when itroducing <jx:import src="static-uri"/> is 
resolving script uri value at runtime. After first page hit the imported 
script is cached separately anyway. It has to be looked up anyway - 
otherwise we get the same problem as today with xslt: you have to touch 
main xslt if you change the imported ones.

Let's leave the feature not changed.

-- 
Leszek Gawron                                                 MobileBox
lgawron@apache.org                              http://www.mobilebox.pl

Re: JXTG further development

[Daniel Fagerstrom <da...@nada.kth.se>]

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