[
https://issues.apache.org/jira/browse/XALANJ-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788310#action_12788310
]
Adam Jenkins commented on XALANJ-2510:
--------------------------------------
Hi Henry,
You make a fair point on xsl:variable vs xsl:with-param, if I extend the patch
to xsl:with-param, are you happy to commit it?
As for a named template call from an xsl:variable, my patch doesn't change any
existing functionality...it's just an IF statement that MAY be used by an
extension element. If they do that, it will work exactly the same as it
currently does, I haven't changed any of that functionality.
And as I said...this is exactly how extension functions work...I've basically
just done the same thing for extension elements. You can't use an extension
function in the way you've specified, so why should it be a problem for
extension elements?
The whole extension element, within an if, within a variable, that happens to
want to set an object. I have to ask how many people would even likely to hit
that? And if they do, can they not submit their own patch when they come up
against it to enhance my changes? Why does the scope for a patch that has a
specific use, and adds a fair amount of functionality, have to be increased to
cover all possible conceivable uses...especially when it's an optional piece of
functionality, used by very few users of Xalan. What percentage of your user
based writes extension elements, and what percentage of those are going to hit
that problem described, and what percentage of those are going to be unable to
declare the variable ahead of time, and what percentage of those are going to
be unable to submit their own patch to solve it....because that's the group of
people we're talking about here, we're holding up a current user need for a
fairly low probability theoretical users need.
Isn't the whole point of open source to grow slowly over time with user need,
patch by patch? Isn't the whole reason that agile methodologies have taken off
because they do only what is needed to solve the current problem rather than
thinking up every possible solution...I mean, if ever anything fell into YAGNI.
Martin has expressed a concern with how I've implemented the entity manager
extension element over on sxe.dev.java.net. Fine, no problems, I possibly
think it should have been raised over there, but I've included his suggestion
about default="yes/no" on that extension element.
Using a placeholder xml I have a problem with as it's very different to how
extension functions and Transformer.setParameter(...) currently work. It would
require post processing of the transformation which is a massive change for a
small piece of functionality...so again, YAGNI on the one.
As for accidently serializing an object, well, people can do that at the
moment, either by getting it from an extension function or passing it into
Transformer.getParameter, so unless you want me to also change them, one of
which is part of the spec, so I don't like our chances there, then I don't
think that concern has a great deal of merit.
So back to xsl:variable vs xsl:with-param. If I make the same changes to
xsl:with-param and resubmit the patch, will it go through?
If anyone has a better way of doing this....let me know, happy to rewrite it
all.....but given it took me so long just to get this little patch noticed, it
doesn't fill me with hope that this ability (which is a blaring architectural
inconstistency between extension functions and extension elements if you want
to get into inconsistencies...maybe I should have made it a bug) will be in
Xalan any time soon.
If I sound a bit p-d off, it's because I am....for years I've been defending
Xalan to my peers against the massive onslaught of "switch to Saxon" (and I
teach across Australia for the most active java training institute over here,
so when I say peers, I mean pretty much everyone I meet whenever I do an XSLT
or a Java course)...so when I was charged with enhancing my existing extension
functions and elements with a couple of others and releasing them (that caused
this issue), I had a choice, Xalan or Saxon....I chose Xalan to inject a bit of
life into it and this is what I hit....the exact philibustering that I was
warned about.
As for keeping the ticket open but rejecting the patch...fantastic, if you've
got someone else lined up to code it I'm happy to use their solution? Do you
have an ETA on it so I can plan my work around yours? Like I said, I'm happy
to code, use, do anything that gives me the ability to set a variable from an
extension element...but all I'm getting is a bunch of what-ifs with no real
suggestion to how you would like this changed (post processing an XML document
for placeholders aside).
Otherwise...what do we do....."no sorry Adam, we don't like your patch and
won't give you direction as to how we would like it, so you can just stall all
your plans and keep submitting until you happen to hit upon something that
gives us the warm and fuzzies"?
Is there an escalation strategy at Xalan...who makes the final calls on these
things? Is this the end of the line for this functionality based on random
what-ifs and YAGNI functionality? You're not exactly filling me with
open-source contribution love here guys. I have a real need, today, which is a
blocker on my project, that is being canned based on theoretical corner
cases...doesn't that fly in the face of what open source is supposed to be
about? Many people, making changes based on their current needs slowly
building and enhancing a project over time?
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
