Re: [xsl] JAXP Saxon Extensions and Java Objects

Subject: Re: [xsl] JAXP Saxon Extensions and Java Objects
From: "Mark R. Diggory" <mdiggory@xxxxxxxxxxxxxxxxx>
Date: Tue, 28 May 2002 17:17:54 -0400

Michael Kay wrote:

I've got several java objects I'd like to hand to an extension behind the scenes. In theory I could hand them as parameters to the transformer and set them in attributes of my extension element. But a more elegant solution would be to get them somehow into the Context.getController().getUserData(...) hash via some method I'm hoping is available in Saxon for this. Or a method that might exist in JAXP as well? Please, any tips would be great.

There are various ways you can do this. Certainly, you can use the
setUserData() and getUserData() methods on the Controller object to pass
data into extensions. Or you could simply pass a Java object to the
stylesheet as a parameter, and then pass the parameter as an argument to
an extension function. Or you could initialize an instance of your
extension class before starting the transformation, pass this instance
as a parameter, and then invoke instance-level methods on the class by
passing the instance as the first argument to the extension function

Michael Kay
Software AG
home: Michael.H.Kay@xxxxxxxxxxxx
work: Michael.Kay@xxxxxxxxxxxxxx

Yes, it looks like this will work nicely. We did a test just setting the objects as jaxp parameters as usual and the picking them up from the Controller object. However, it took be a few minutes to realize that the parameters stored in the controller are wrapped in Saxon classes of thier own. But once I caught on it was smooth sailing. One question, why are there "UserData" and "Parameters" in Saxon? What is "UserData" usually used for?

We're starting on some extension packages for Saxon now, roughly just interfaces for the following libraries: The Servlet API's javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse, javax.servlet.http.HttpSession, javax.servlet.ServletContext and JNDI's (with both read and write capabilities). Why? you might ask. Because we want these capabilities in XSLT without the overhead of other product architectures (Apache Cocoon and the like). This will just be a small set of classes to extend the capabilities of Saxon into the JSP/Servlet Realm.


XSL-List info and archive:

Current Thread