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/
