D
Duane Morin
Is this normal use of XSLT? At the top of our XSL file we have:
<xsl:stylesheet ...
xmlns:nl="http://www.jclark.com/xt/java/com.company.package.ProcessXML">
....
Then within the XSL itself we call:
<xsl:value-of select="nl:generate-url('x', 'y', 'z')" />
Where generate-url is actually defined in ProcessXML.java:
public static String generateUrl (String x, String y, String z) {
...
}
This works just fine when I'm performing the XSL transformation within
my own Java app that has access to the ProcessXML class. However, it
completely ruins my ability to use an XSL editor or do any type of
external transformation which aborts with an exception about not being
able to find the generate-url function.
So my question, since I didn't write this code , is this standard
procedure for extending XSL to do what you want? If so, is there
something that I'm missing which would enable a standalone XSL
transformation engine (such as might be found in an IDE) to recognize
the functions I added? Is there a way that I could write some sort of
stub/dummy plugin for generateUrl that would do nothing, but at least
keep the transform from failing?
This approach has served us fine in a world where the Java guys also
did all the XSL coding and so always worked within the scope of a Java
app, but we're getting to a point where we'll have dedicated content
people and I'd like them to be able to use an XSL editor of their
choice. Right now the only option is "Edit XSL, check in to source
control, request a rebuild (since they cannot build the product on
their workstations), look at results, repeat."
Thanks!
<xsl:stylesheet ...
xmlns:nl="http://www.jclark.com/xt/java/com.company.package.ProcessXML">
....
Then within the XSL itself we call:
<xsl:value-of select="nl:generate-url('x', 'y', 'z')" />
Where generate-url is actually defined in ProcessXML.java:
public static String generateUrl (String x, String y, String z) {
...
}
This works just fine when I'm performing the XSL transformation within
my own Java app that has access to the ProcessXML class. However, it
completely ruins my ability to use an XSL editor or do any type of
external transformation which aborts with an exception about not being
able to find the generate-url function.
So my question, since I didn't write this code , is this standard
procedure for extending XSL to do what you want? If so, is there
something that I'm missing which would enable a standalone XSL
transformation engine (such as might be found in an IDE) to recognize
the functions I added? Is there a way that I could write some sort of
stub/dummy plugin for generateUrl that would do nothing, but at least
keep the transform from failing?
This approach has served us fine in a world where the Java guys also
did all the XSL coding and so always worked within the scope of a Java
app, but we're getting to a point where we'll have dedicated content
people and I'd like them to be able to use an XSL editor of their
choice. Right now the only option is "Edit XSL, check in to source
control, request a rebuild (since they cannot build the product on
their workstations), look at results, repeat."
Thanks!