cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: sitemap, jx and flow design (was: servicemanager and jxtg)
Date Tue, 25 Jan 2005 22:17:35 GMT
Conal Tuohy wrote:
> Daniel Fagerstrom wrote:
> 
>>Instruction Inclusion
>>=====================
>>
>>Now for the instructions (jx:forEach etc) we have the 
>>question if they 
>>should be choosed:
>>
>>1. Programatically: There is an abstract base class with 
>>common template 
>>generator functionality. To implement e.g. JXTG this base class is 
>>extended. And the extended class enumerates the instructions 
>>that should 
>>be used and also choose parsing strategy etc.
>>
>>2. Configuration: Instructions or set of instructions are made 
>>components and connected to the template generator in the 
>>configuration.
>>
>>3. Within the template language: There are special 
>>instructions in some 
>>common base template language that allow the user to include sets of 
>>(Java written) instructions.
> 
> 
> What kind of instructions did you have in mind? 

Take a look at 
src/blocks/template/java/org/apache/cocoon/template/jxtg/instruction/* 
in trunk. It is al the jx:* stuff in JXTG.

We are factoring out the instructions from the execution engine and the 
compiler to be able to reuse the different part in e.g. an attribute 
template language, see http://wiki.apache.org/cocoon/Templates for more 
details. The refactoring is also to make JXTG more maintainable.

> The reason I ask is I wonder if it's really necessary to add extra instructions to the
template language? A language with conditionals, iteration, AND recursion is surely already
Turing-complete, and doesn't really need more control structures? 

We probably shouldn't add new types of instructions. But some of the 
current instructions have design flaws as you can see in some other 
current threads. E.g. jx:set is somewhere between the declarative 
xsl:variable and an asignement in e.g. Java. jx:eval requires quite 
strange hacks to be usable, jx:import makes pre compilation of macros 
hard (or impossible), there might be other issues as well.

If we just "corrects" the current construction that will break existing 
templates, and we don't want that. So the best things is probably to add 
new more well behaved instructions and possibly deprecate some of the old.

An alternativ would be support both a JXTG 1.0 and JXTG 2.0 and remove 
the instructions we don't like from JXTG 2.0. But currently it seem 
smother to go for the evolutionary approach.

/Daniel

Mime
View raw message