cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <gkossakow...@apache.org>
Subject Re: Object Model-related changes in Template generator
Date Sat, 14 Jul 2007 13:37:36 GMT
Joerg Heinicke pisze:
> 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.

I know and it makes me feel even more grateful for your attempt. :-)

>>     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?

They have different life cycles:
   * executionContext is created only once, at the beginning of template processing
   * macroContext is overrided every time macro is executed
   * expressionContext has the same life cycle as executionContext

It's a good idea to consider merging some of them.

> 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.

You are right, but since namespaces are also used for generators purpose it makes sense to
have a separate parameter for it.

> 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 
> somewhere.
> 
> 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.

Yes, I'll go with fat solution for now and decide later what is really needed. Also, I think
that ExpressionContext should be passed to 
Expression by Spring and not by caller.

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/


Mime
View raw message