Gary L Peskin <[EMAIL PROTECTED]> wrote:
> What do you think about creating a _qn field
> in VariableStack that would be a QName array.
I would rather not. The variable stack itself is very clean now and I
would rather keep it that way. I don't think a penalty should be imposed
for the (forgive me) edge case of variable access by extensions.
Can't Norm's problem be fixed by sensing when you are at the stylesheet
level, and then switching to the global variable list in StylesheetRoot?
Though the hack in Variable#execute and VariableStack#getVariableOrParam
are ugly, and not what we want in the long run, at least for now they are
well contained. They actually wouldn't be so much hacks if they were not
in the XPath module.
Here's what I think we should do instead: change the current VariableStack
into an interface for the use of XPath. When an XPathContext is created,
the caller (Xalan XSLT in this case) passes in a
org.apache.xalan.transformer.VariableStackImpl, where the current code is
moved to. Then, getVariableOrParam is no longer such a hack, and we can
add getVariableOrParamIndex for calling where the current hack is in
Variable#execute.
[aside: Well, getting the stylesheet element from the prefix resolver is
still a hack. But this is general problem and not directly related to the
variable hack. :-) In other words, we shouldn't have to 'hack' in order
to get the current stylesheet context from within an expression. We should
probably just have a method like Object getContainingContext() or some such
in XPathContext. This isn't that much different from getNamespaceContext
()... but it would look nicer in the code. ]
I've had a pretty long day, so this may not make any sense when subject to
scrutiny. Does this hold water?
-scott
