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
|