[jira] Commented: (XALANJ-2510) Ability to set non tree fragment variable using an extension element (PATCH SUPPLIED)

["Martin von Gagern (JIRA)" <xa...@xml.apache.org>]

    [ https://issues.apache.org/jira/browse/XALANJ-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787413#action_12787413 ] 

Martin von Gagern commented on XALANJ-2510:
-------------------------------------------

Changes to behaviour depending on element context feel like a really bad idea to me. This is because what the user intends and how the element interprets the situation might be quite different things. For example if I as an innocent user of that library were to use some conditional like Henry suggested, and ended up accidentially setting some global entity manager, I might become quite unhappy.

So from the user perspective, I would wish for the behaviour of elements to not depend on context. Instead I'd prefer some attribute to change behaviour where appropriate, e.g. defaultManager="yes|no" or output="object|stderr" or whatever.

As for the implementation, how about using placeholder elements? The custom elements could return <placeholder xmlns="some-internal-namespace" index="42"/> and keep track of the association from the index 42 to the actual object in some kind of auxiliary data structure available for the whole process, e.g. through an Object-valued xslt variable set by the caller. The fact that you already have a global default manager suggests you know a suitable way to get such per-transformation variables. Functions dealing with the objects represented by such placeholders could then inspect whether the node (list) they are given is a placeholder, maybe with some whitespace around it, and if so, retrieve the associated object and use that.

The benefit would be that all of this could be implemented in the extension library, without any modifications to xalan itself. It would therefore be much easier to deploy, and much easier to port to other processors. Furthermore there'd be much less corner cases to deal with, e.g. what would happen when arbitrary objects end up getting serialized to xml. And with the use of placeholder elements instead of opaque object variables, users would have all the power of xslt at their disposal; not only conditionals and template invocations, but arbitrary third party extensions as well.

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