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
