Daniel Fagerstrom wrote:<snip/>Stefano Mazzocchi wrote:
Stefano,
The last two paragraphs are a little bit vague to me. I need your and others opinions about how we should handle this in the refactored JXTG. We are in the progress of factoring out the, (hopefully neutrally enough named), instructions from the template execution engine and compiler. This is for increasing maintainability, SOC and give the possiblity to implement an attribute template language that reuse some of the parts. We are also factoring out: expression language, parsing of strings with embeded expressions and the object model.
Daniel, thanks for the summary. Read my comments below.
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.
I would prefer the configuration way find the programatic way ok and be against the within the template language way.
WDYT?
This really looks like just an implementation detail... I would think that the configuration way makes it easier (psycologically) for people to add their own instructions than the other two. #1 is cleaner than #3 and less avalonish than #2.
I'm not thrilled with the idea of people adding their own keywords to the template language... just like the sitemap, it should be possible but not easy, so that people would feel discouradged to do it. So probably #1 would be my choice.
Ok, if no one protests I think we go for #1. It give us more flexiblity in refining the instruction interface than if we publish it as an "external" interface. We can always do it configurable later if the need is feeled.
Instruction Access ==================
What objects should instructions and macros be able to access? Curently for the needs of the JXTG instructions, the instructions has access to a ExpressionContext that contains the FOM "view" that is available in expressions in JXTG. They also have access to an ExecutionContext that currently contains a script manager and a map with macros, we might need a SourceResolver also. There are also some other stuff that not are relevant for the current discussion.
The questions are:
* Should the ExecutionContext also contain a ServiceManager?
* Should the ExpressionContext also contain a ServiceManager? (makes the ServiceManager available in expressions)
IMO the ExecutionContext should have access to the ServiceManager and the ExpressionContext shouldn't.
WDYT?
Agreed. Seems reasonable.
Ok, good.
/Daniel
