> I don't think this is resolved at
> compose time now (though I may be wrong) so you'll need to figure that
> out at compose time and perhaps that information, also, could be saved
> so that locating the target template at runtime can avoid a runtime hash
> lookup, which is, I think, the way it works now.
No, I fixed this in XalanJ2. It is resolved in the compose method.
> I guess you'll have to copy the value of the
> parameter in the calling template slot into the called template slot.
> Is that right?
Yes.
> However, when you copy it,
> you'll have to remember from whence it came because the evaluation needs
> to be done in the context of where the xsl:with-param occurred, not the
> context of the xsl:parameter.
Right, the evaluation has to occur abstractly before the copy into the
slot. In reality, XUnresolvedVariable takes care of the details of lazy
evaluation.
> Also, does it then get copied
> back to the invoking slot?
I don't think there is an invoking slot. I think the answer to this is no.
> If not, it will have to be reevaluated the
> next time it's passed which is not a good thing.
Well, what gets passed is a reference, so I'm not sure this causes problems
by itself. But, yeah, there are some details here. A
call-template/with-param need not worry about this, right? An
apply-template should (abstractly) evaluate once in the context above the
apply-templates, and then pass that evaluation multiple times to each
invoked template. This is the way it is done today (unless I am mistaken),
and I don't think this part changes. See
ElemForEach#transformSelectedNodes and ElemApplyTemplates#pushParams.
There are some tricky parts about which side of the stack frame the
evaluation occurs on, but, hopefully, this will get a little easier.
> If the expression in
> the xsl:with-param, in turn, references other parameters that get
> passed, this will have to be represented/remembered somehow.
I'm not sure I understand this.
> When the xsl:copy-of gets executed, where is the slot that the
> expression and result go in? In b or c? As we evaluate b in the
> context of template b, we need to switch to context a to evaluate
> variable a. Then, does the evaluated value of variable a remain in the
> slot in a?
Again, I'm not sure I understand this. There is no result (templates
currently can not return values). The variables are (abstractly) evaluated
before the template is called. As I write this, I am a little worried
about how XUnresolvedVariable works, since, once it is evaluated, the
original reference has to be replaced. So, I think you're right, the
parameters may have to be copied back to the caller.
> I only point these issues out to make sure
> that you've thought of them, since you did ask.
I appreciate very much the input. The danger of a design such as this is
missing details, and you've helped me think through some of the issues.
Just writing it down helped with this also. Hopefully I can pull this off
fairly cleanly.
-scott
