[ 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: xalan-dev-unsubscr...@xml.apache.org For additional commands, e-mail: xalan-dev-h...@xml.apache.org