Re: [xsl] JAXP Saxon Extensions and Java Objects

["Mark R. Diggory" <mdiggory@xxxxxxxxxxxxxxxxx>]

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
> call.
>
> 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 
javax.naming.directory.DirContext (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.

-Mark



XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list