[
https://issues.apache.org/jira/browse/XALANJ-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787735#action_12787735
]
Adam Jenkins commented on XALANJ-2510:
--------------------------------------
Ok, first thing that I ask, is don't get hung up on a particular example that
may be given. I'm picking these examples at random, there are heaps and heaps
of different extension elements and delving into the exactly perfect
architectural design for each one is a bit of a red herring for this issue. I
don't expect the Xalan crew to take ownership of SXE.dev.java.net as it's an
extension and will never be part of xalan because it doesn't fit the use case
of Xalan. So if you wish to discuss whether the entity manager should be
global="yes/no", I think that conversation is best served for the mailing list
at SXE.dev.java.net.
As for maintaining a seperate variable stack...my response to that would be
"why?"....there is a perfectly valid way of managing and resusing variables and
parameters in XSLT...should everyone writing an extension element have to
create what is essentially their own interpreter and variable context?? If
that's the case, why aren't they forced to do that from extension functions?
Your post has a lot of "what if" scenarios...what if someone serializes an
object to XML? Well, they can do that currently....have you ever used
document() and loaded the wrong document, or used any extension functions to
load an object? Should we design our software for every possible
contingence...if so, are we likely to ever get anything done?? And as for
making it portable across processors...it's almost impossible that it would
actually be portable even if I did what you suggest, the extension element
framework is just too closely linked to the xalan code...to make it portable I
would have to extract an interface for every piece of commonality between Saxon
and Xalan and code to that interface, which would require a far bigger change
to the Xalan base than I'm currently proposing.
I could come up an infinite number of reasons why a change like this is both a
good and a bad idea. As I could for any other change to any other
system....there is no right or wrong way to implement a solution whos
constraints are almost entirely virtual (and I say this with 12 years
enterprise architecture experience and a SCEA, SCWCD, SCBCD and SCJP
ticket)...sooner or later someone just has to make a call as to wether the
supplied value outweighs the impact to existing system. There is obviously a
pretty good case that it does, otherwise why would extension functions already
have the functionality?
I guess I fail to understand why allowing a simple 5 line change to one
component (ElemVariable) to allow extension elements to do something that is
already allowed in extension functions warrants such concern or objection.
Especially when the impact to existing transformations is exactly zero.
Anyway, this very simple, very low impact patch has been sitting here for a few
weeks now....can someone either approve it or reject it so I can get to porting
my extensions over to Saxon if I need to.
Cheers
Adam
> 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
