[ 
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

Reply via email to