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