[
https://issues.apache.org/jira/browse/XALANJ-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12783695#action_12783695
]
Henry Zongaro commented on XALANJ-2510:
---------------------------------------
Hi, Adam.
Thank you for the contribution.
I've taken a quick look at your patch. One thing I notice immediately is that
it applies to xsl:param and xsl:variable, but I expect you would want it to
apply to xsl:with-param as well - right? And probably the EXSLT func:result
element, too.
I'd also like to understand how this interacts with other features of the
language. Without a sample implementation of an extension element like the one
you've posited, it's difficult to tell whether this new feature is
well-integrated.
For instance, suppose I make the extension element in the content of an xsl:if
or xsl:choose to evaluate it conditionally, will that work?
<xsl:variable name="myvar">
<xsl:if test="condition">
<my:extension someAttribute="somevalue"/>
</xsl:if>
</xsl:variable>
The way you've written the patch, it looks like you're expecting this kind of
element that needs to return an "override" value to be a child of an
xsl:variable/xsl:param. Similarly, what if the extension element is in the
dynamic scope of an xsl:variable rather than the static scope - i.e., what if
the xsl:variable contains an xsl:call-template, and that named template
contains the extension element. How does the override get set on the
xsl:variable that contained the call? Again, a sample implementation of such
an extension element might have helped to clarify the way the mechanism works.
Finally, I wonder about the way the result is set on the xsl:variable is
through this mechanism of supplying an alternative XPath expressions, rather
than somehow integrating it as a different result kind.
By the way, it's important that any contribution that's not completely trivial
be covered by a contributor's license agreement. That assures the ASF that you
have the right to make the contribution. May I suggest that you submit one?
You can find it here.[1]
[1] http://www.apache.org/licenses/#clas
> Ability to set non tree fragment variable using an extension element (PATCH
> SUPPLIED)
> -------------------------------------------------------------------------------------
>
> Key: XALANJ-2510
> URL: https://issues.apache.org/jira/browse/XALANJ-2510
> Project: XalanJ2
> Issue Type: Improvement
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
> Components: Xalan-extensions
> Affects Versions: The Latest Development Code
> Reporter: Adam Jenkins
> Fix For: The Latest Development Code
>
> Attachments: XALANJ-2510.patch
>
>
> When using extension elements, there is no way to set a non XRTreeFrag
> related variable.
> For example, say you have:
> <xsl:variable name="myvar">
> <my:extension someAttribute="somevalue"/>
> </xsl:variable>
> If my:extension wants to set a tree fragment, string or nodeset into myvar,
> that's not a problem, however if it wants to set a java object, currently
> there is no mechanism for that (any java object passed either returned from
> the method or passed to XSLProcessorContext.outputToResultTree is
> toString()'ed before being passed back to the ElemVariable.getValue() method).
> The proposed change (patch supplied) is to supply an optional variable on
> ElemVariable.java whereby child extension elements can call up to their
> parent and set an XPath to be evaluated after the extension element has
> finished processing.
> This requires only very minor modification to the ElemVariable.getValue
> method to check this variable.
> This also ensures that this is optional functionality and will not affect
> that basic Xalan processing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
