Stefano Mazzocchi wrote:
BURGHARD Éric wrote:
WAIMS (where am i missing something ? :-)
XSP was designed to achieve exactly what you are describing. Sure it has some limitations and the use of xslt to generate java code is not exactly appealing, but it supports exactly that programmatic model. Still everybody seems to hate it (I still use it, but only as a faster way to write custom generators, not as a template language).
I think the reason is that what you want to achieve seems practical, but it normally turns out in hell.
Example: the difference between <get-users/> and ${get-users} is that the first invoques a function (thus could trigger an exception) the second refers to a variable, which, at worst, might be unset or empty or contain a wrong value.
As soon as you realize this, you also realize that you need conditionals in your language semantics... and if you hit the <if> tag, you are dead.
What you are asking for are not taglibs but functional macros... the ability to invoque a function/service/method instead of just reference a variable... this allows you to drive the control directly from the template, instead of having the control inverted by the flow controller.
I think this is a reasonable request and I see nothing wrong in it, but these have nothing to do with taglibs, are more similar to what input modules are for a sitemap.
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.
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.
-- Stefano.
