[
https://issues.apache.org/jira/browse/XALANJ-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788714#action_12788714
]
Martin von Gagern commented on XALANJ-2510:
-------------------------------------------
> should everyone writing an extension element have to create what is
> essentially their own interpreter and variable context
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. The
upside is ease of use for extension writers, a possibility to replace its
implementation inside Xalan at some later point in time without impact on
existing extensions, and of course it avoids code duplication. On the downside
we'd reserve a namespace for Xalan internal use, which should be perfectly
legal but feels bad nevertheless, 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.
> 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...
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.
A bunch of patches, each requiring adjustments not only to Xalan but to the
extension elements as well, until the concept finally integrates fully with
xslt, i.e. behaves the way writers of xslt stylesheets would expect it to,
seems to me an indication of bad design. So even if the patch does fix your
current problem, and if future problems could be addressed in subsequent
patches, 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.
>From the point of view of an extension writer, I would wish for my extension
>element to simply return an object of arbitrary type, instead of performing
>some kind of unintuitive set-value callback. That's what the current Xalan-J
>online documentation would suggest to me, too. So if there is a way to simply
>have an extension element return an object of class FooBar, and an extension
>function accepting an argument of class FooBar, and if we could link the two
>using an xslt variable on the Xalan side, then I believe we should implement
>this way. xml placeholders go part of the way, but
> Using a placeholder xml [...] would require post processing of the
> transformation
How so? There are three possible points where you could turn placeholder xml
back to objects:
1. inside the extension functions dealing with such objects, as I suggested for
an extension-only implementation
2. inside the xsl:variable et al. upon assignment
3. just before calling extension functions, i.e. when preparing the argument
list
None of them feels like a lot of post-processing, but instead like a single
lookup in a single place at the time an object is needed, for a given
definition of "needed". As neither objects nor placeholders are intended for
serialization,
> If I make the same changes to xsl:with-param and resubmit the patch, will it
> go through?
> I'm happy to code, use, do anything that gives me the ability to set a
> variable from an extension element...
I'm not a committer to Xalan-J (yet), so I can't give you authoritative answers
here. If I were, I'd tell you that I've got the feeling your implementation is
a hack, that a more proper solution that integrates more naturally should be
possible. The "what if" scenarios are not only concerns about your patch
failing to address these, but an indication of a concept in need of
improvement, as is the fact that a simple change to function return type for
extension element implementations doesn't do the trick.
I'd furthermore ask you that if you want the code in Xalan (as opposed to your
own lib), then I'd suggest you try out the replacement element approach, so we
get a better idea about its impact on exported API, performance, affected
locations in the source code, security issues, integration with xsltc and so
on. If I were a committer, I'd see good chances that I'd eventually commit a
patch along these lines. If you come up with an even better idea, I'd be happy
to hear it.
> someone just trying to understand a big code base with no assistance
I feel the same myself.
> 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
