cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: Object Model-related changes in Template generator
Date Fri, 13 Jul 2007 18:56:42 GMT
On 12.07.2007 16:34, Grzegorz Kossakowski wrote:

> it's rather JXPath-specific feature.

> Namespace table is also very specific to JXPath

I understand your concerns. Unfortunately, it's hard to give any advice 
without knowing the internals.

>     public Event execute(final XMLConsumer consumer,
>                          ExpressionContext expressionContext,
>                          ExecutionContext executionContext,
>                          MacroContext macroContext, Event startEvent, 

What are all these contexts about? Couldn't they somehow be merged? What 
are their life cycles? Are they all different? Isn't for example the 
namespace context quite similar to a variable context? Or asked in 
different words: Isn't a namespace prefix something like a variable? 
 From a short look on the code (only via ViewVC, no Eclipse) similar 
stuff seems to happen with Java packages for Rhino 
(FlowObjectModelHelper.addJavaPackages()). I wonder if this makes sense 
for all cases.

Decoupled from the names and concepts used in the current 
implementation: What is actually needed to evaluate an expression? The 
expression itself and the context it is evaluated in. This expression 
context stores all information in it the expression can or needs to 
access like for example the namespaces.

 From what I see there is only one expression context during the 
rendering of a template at the moment. It might be necessary to create 
one expression-specific per expression. They can then also be expression 
language specific and Expression.evaluate() could retrieve expression 
language specific information like namespaces from it. The current 
ExpressionContext would get a very simple interface not aware of 
concepts like namespaces. Since those "things" need to get injected on 
instantiation of the ExpressionContext there also needs to be somthing 
that keeps track of those "things". These track-keepers have different 
information needs per expression language, so they need to be registered 

Hmm, this sounds like a major change - maybe not even reasonable without 
knowing how it is really supposed to work. Does it make sense? Maybe you 
should really go with the simple and "fat" solution for the moment since 
those expression language specifics are "in" at the moment anyway.


View raw message