[
https://issues.apache.org/jira/browse/XALANJ-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12783833#action_12783833
]
Adam Jenkins commented on XALANJ-2510:
--------------------------------------
Hi Henry,
Yep, you're correct re xsl:param and xsl:variable. I didn't really consider
xsl:with-param or func:result, as I guessed that if people want to do that,
they can just create a variable first and pass that to the with-param. I only
chose to modify ElemVariable so as to keep my impact on Xalan base minimal.
As for a sample, it depends on the use case and there are a lot of use cases :)
Usually I first test the parent thus:
protected boolean setVariableIfPossible(Object variable, ElemExtensionCall
thisElement){
if(thisElement.getParentElem() instanceof ElemVariable){
ElemVariable varElement = (ElemVariable)thisElement.getParentElem();
varElement.overrideChildDocument(new XPath(new XObject(variable)));
return true;
}
return false;
}
if this returns false, the action is different for each extension element. For
instance, I have an element that configures a JPA entity manager that is used
thus:
<xsl:variable name="entityManager">
<jpa:entityManager persistenceUnit="myPU">
<jpa:property name="flush" value="true"/>
</ejb:entityManager>
</xsl:variable>
Now, if that isn't inside a variable element, it sets up a default
entityManager for the entire transformation. However, I have another JPA
element called query that is used thus:
<xsl:variable name="customers">
<jpa:query name="customer/name" location="customer/address/city"
type="customer/@type">
from Customer c where c.name = :name and c.city = :location and
c.customerType = :type
<jpa:query>
<xsl:variable>
where the attributes of the extension element are mapped to the named
parameters of the JPA query. Now if this element isn't inside a <xsl:variable>
element, then the response is output as per standard:
context.outputToResultTree(context.getStylesheet(), queryResults);
I hope those two above give you a bit more of an idea of some of the stuff I'm
doing. The entire collection of extension elements/functions is open source
at sxe.dev.java.net (though I think it's still going throug approval, so you
might have to log in to see it, or ask me for permissions or something, I don't
know how it works for pre-approved projects...let me know)....I know the code
in there isn't the best, so be kind ;). Also, I know some of the stuff that
those extensions allow you to do may not be considered best practice, however
sometimes they come in handy :)
In terms of the dynamic scope question, the answer should be addressed above,
each of my extension element has a different strategy for when it's not inside
a xsl:variable element, and it's up to the users of the library to read the
doco and understand the impact on their transformations.
In regards to using an XPath...may not be the best solution, I just tried to
keep things as similar to how Xalan was currently doing things as possible so
as to minimize my impact on the project :). One of my primary motivations
while thinking about how to impliment this was how to keep the impact on Xalan
to an absolute minimum, so I chose the shortest path to accomplish my goal :)
I hope the above helps understand the motivation for this change a little more.
Feel free to checkout sxe.dev.java.net. I know some of the things it does are
considered not exactly best practice (for example, being able to send an email
from an XSLT or being able to write to a graph to a parallel binary stream),
however it's an optional library, so I expect users of it to understand the
pros and cons of breaking some of the XSLT best practices.
I'll submit the license agreement you posted a link to sometime today (for some
reason, my ISP blocks apache, so I have to wait until I get to work :) ).
> 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
