tree 432f89114aff063736d76eb797c5cccb50b0cddc
parent 6af1db0cca6c8553120b2f7125ebb545f2b21d72
author Scott Boag <sboag@apache.org> 992987529 +0000
committer Scott Boag <sboag@apache.org> 992987529 +0000

Nasty hack.  The issue is that extensions are
building their xpaths on the fly, so they don't really
have a chance to fix up their index lookup for the
variable stack (this problem caught me a bit by
surprise).  The variable stack itself no longer has
any qname information... it's a straight index lookup
to the variable value.  In order to work around this
problem in the short term, I test whether
fixupVariables has been called, and, if it hasn't, I
take the current prefixResolver, *which must be
set to the extension element* (it wasn't in the
Redirect extension), test if it is a
ElemTemplateElement (bad because we're not
supposed to be coupled with the xalan package
in xpath), and look at the previous sibling and
ancestor previous siblings for a ElemVariable.
For each ElemVariable, I can then compare the
qname, and, if a match, get the index from that
element.  Right now it doesn't do anything special
for global variables, and so errors can occur in
this case if you have imports and includes and
the like.  The hack is good enough right now to
get fop codegen to work correctly.  I'll do some
more work on this next week, or someone else
can, and I'll try and figure out a way to do this
without the visibility to xalan.