[
https://issues.apache.org/jira/browse/XALANJ-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788750#action_12788750
]
Adam Jenkins commented on XALANJ-2510:
--------------------------------------
this is getting <censored> ridiculous...2 pages of architectural filibusturing
for the simplest patch I've ever submitted anywhere, ever. Discussions about
how something "feels", I mean come on.
But here goes, one last try at this complete freakin' insanity.
>>If there are indeed several writers of such extension elements, then it would
>>be possible to do the very same process I suggested inside Xalan itself.
Why not just use the structure that's already there!? I don't understand...why
do you want to create 2 xpath contexts, one outside of xalan and one inside.
Also, don't give me generic architectural concepts in your answer...give me
java file names...where do you want to extend from, how do you intend to
interact with the current processor. Is this external processor also supposed
to use XObject...what about the ElemVariable preprocessing where indexes are
assigned, how do we fit in with that so that our external variables are usable
from within xpaths in our XSLT?.
>>in particular if you consider that documents from insecure sources might use
>>this mechanism to suddenly refer to objects in a way the writer of the
>>stylesheet never intend. So there is a security risk there. So this should be
>>carefully thought through, maybe by using random keys instead of sequential
>>indexes, so guessing valid object elements becomes infeasible.
I'm sorry to ask it...but are you high?! Security risk? Inside an
XSLT...what! You're proposing people randomly load XSLT into their
organisations from insecure sources and you're worried that MY patch "feels"
odd?!? Seriously, if someone can inject random XSLT transformations into your
organisations you've got waaay bigger problems than what they're going to be
doing in XSLT. I can tell you now, if I can put random XSLT into an
organisations integration platform, then I already have all the security access
I need to do pretty much anything I want. This is a complete red herring and
has no bearing on this issue at all.
>>After rewriting a bunch of projects from scratch, and a few more in the
>>queue, I've learned the value of a good concept before I start to code.
>>Beeing rash to get the first features out will likely hinder later
>>development if the underlying concepts are not sound and flexible enough.
Refactoring, by Martin Fowler....buy it, read it. The days of BDUF (Big
Design Up Front) have been dead in our industry for many years now. And when
you say bunch of projects...what are we talking here, $4mill, $12mill?? Or are
these just your own projects? Because I can tell you from experience that some
of the biggest and most high profile projects in the last 5 years have been
written exactly the opposite to how you suggest, hell Thoughworks have made a
multinational business out of it. Agile (XP, Scrum, FDD) is our fastest
growing area of training and has been that way for quite a few years....none of
those 3 methodologies do BDUF. In fact, BDUF is generally seen as a risk
factor for project failure.
>>I'd rather wait a bit longer to think about possible concepts, and then
>>implement some concept that will allow a smooth ride from the first feature
>>to the final full-featured improvement, without hacks at every corner and
>>without breaking compatibility in between.
You make so many assumptions here....that because you don't have a BDUF, it's a
'hack'....go tell Kent Beck that all his very successful projects were
hacks...and who says even if something is a hack it's going to break
compatibility?? Isn't that what a unit test is for?? All through projects,
all over the world (including Xalan) there is code comments with things like
"this is a bit of a hack, could be done better in the future" which has been
working fine for years. If everything that's written has to fit your arbitrary
"feel good" rule, I'd hate to see how much code is going to actually make it
into production. Just writing this patch I stumbled across 3 places in Xalan
that had comments talking about how the author would have liked a better
solution but he chose to do the pragmatic thing and get the functionality out
there in a timely fashion.
And who is going to do this BDUF you speak of...who is going to sit down and
think of a gazillion scenarios and then code for them....and what are the
companies that rely on these changes and future innovation meant to do in the
mean time....I can tell you what they're going to do, move to Saxon, because I
see it every day. Xalans too slow, Xalan doesn't have XSLT 2.0, Xalan won't
accept my patches...that's what I hear from clients, every day.
>>So if there is a way to simply have an extension element return an object of
>>class FooBar
It does that currently! Look at the code! You return an object, and it turns
it into a text node and injects it into the result document. As you would
expect. This is about those times when you want to set a variable for use
later rather than having it injected into the output results.
Have you written any extension elements? Because it sounds like you're talking
from an XSLT point of view, you don't seem to be making many references to
where...specifically in the code you would like these changes to occur. If you
haven't written any extension elements, then what are you doing even commenting
here...you don't know what you're talking about and you're just confusing the
issue. If you have, then tell me where you want this 'new object' type (again,
does it subclass XObject...is it being passed as an XPath reference or a java
object?) to be integrated back into the Xalan variable stack.
>>I'm not a committer to Xalan-J (yet),
God help us if you ever become one mate...the complexity you've bought to this
very simple addition of functionality is incredible. You talk about 'feeling'
that this is a hack...come on, seriously?'
Finally, you seem hell set on this XML placeholder replacement approach, even
suggesting that would be my way to expedite acceptance of my bug. You know how
I read that...."I don't like how you did it, but if you do it exactly how I
want it done, we'll let it through". Now project that into the future...is
that your strategy for managing outsider patches?....as long as it "feels
right" for me (which means basically something you design) it'll go
through...otherwise don't botther. Anyone still wondering why this project has
a committer level problem??
You're placeholder design takes a very simple solution and turns it into an
incredibly complex one, requiring multiple processing of the same segment of
code, the use of a placeholder variable and both an extension element and a
function. And isn't your suggestion of handling it inside the
ElemVariable.java just before assignment EXACTLY WHAT MY PATCH DOES? It just
does it as an XPath object, referencing the exact XObject rather than bothering
to write it to an intermediary XML and then cast it back.
Gotta say guys, this is ridiculous.....laughable almost if it wasn't so
serious. In 12 years I've never hit so much sheer conjecture, stonewalling and
filibustering for a contribution to a OS project. I had to contributed some
XQuery stuff to Michael over at Saxon once....he looked at the work, asked me a
couple of questions, suggested some modifications (giving exact files, rather
than random generalised statements) and helped me make the mods, then thanked
my for my work....whole process took about 2 days AND HE WAS ON HOLIDAYS AT THE
TIME! And generally that's what I've gotten elsewhere....I totally live in
fear of ever having to post to these mailing list because I always hit this
same type of architectural filibustering...this project reminds me of the bad
old days when you had to be really nice to a sys admin or he wouldn't give you
an email address.
Anyway, accept it/reject it...who cares at this stage, if this is what people
have to go through to have an input to this so called "Open Source" project.
> 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: [email protected]
For additional commands, e-mail: [email protected]
