cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: sitemap, jx and flow design (was: servicemanager and jxtg)
Date Tue, 25 Jan 2005 09:38:27 GMT
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.


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.

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.

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.

Both the above question might be suitable for votes, but I think they 
need more discussion about them before we do that.


View raw message