Re: Dom and XT

> I have a DOM document and a style sheet URI. How to generate a HTML output
> applying my style and using DOM with XT (without transforming DOM by
> serializing it into InputSource)?

To Transform 'native' DOM you need  XSLTransformEngine.
To generate HTML you need OutputMethodHandlerImpl.

Latest version of XT does not allow easy way to do this.
( I think ).

To transform DOM into HTML with XT you need the trick
described below ( I think ).

I think that in the next  versions of XT the hack
described below will be not needed.

Rgds.Paul.

----- Original Message -----
From: Paul Tchistopolskii <paul@xxxxxxx>
To: <xsl-list@xxxxxxxxxxxxxxxx>
Sent: Tuesday, December 28, 1999 3:29 PM
Subject: Re: Using XT via a Java Servlet?


>
> Writing my answer  to the XSL-list  scares me a bit, but
> I hope I will not say something extremely stupid from
> James Clark's point of view ;-)
>
> If there are some serious mistakes in the text below
> ( I'm taking about XT interlans as I see them ;-) , I hope
> James would correct me.
>
> > Has anyone taken the DOMDemo.java example included in the demo directory of
> > XT and made it work as a Java servlet?  If so, mind sharing your code?  I'm
> > able to use LotusXSL in this manner, but haven't had any luck yet with
> > XT.  TIA,
>
> The DOMDemo utilizes XSLTransformEngine.
>
> I think it could be fair to say that at the moment there is kind
> of *two* transform engines in the latest version of XT.jar.
>
> The 'basic'  and 'well-known' engine ( XSLProcessorImpl )
> takes some 'input', builds the 'XT-specific' DOM and then allows
> you to transform that 'XT-specific' DOM into diferent 'output media'.
>
> You are specifying the desired 'output media' attaching
> the desired destination to OutputMethodHandlerImpl and
> then attaching the OutputMethodHandlerImpl to
> XSLProcessorImpl .
>
> OutputMethodHandlerImpl outputMethodHandler =
>     new OutputMethodHandlerImpl(xsl);
>
>  xsl.setOutputMethodHandler(outputMethodHandler);
>
>  outputMethodHandler.setDestination
>   ( new ServletDestination(response) );
>
> This pattern *does*not* work with XSLTransformEngine.
> I mean that XSLTransformEngine assumes that one is
> utilizing this class for XML-DOM -> XML-DOM only transformations.
>
> However, with semi-trivial subclassing *and* some cut&paste
> I forced XSLTransformEngine to take into account  OutputMethodHandlerImpl
>
> main[]
>
> MySunXMLProcessorImpl reader = new MySunXMLProcessorImpl();
>
> org.w3c.dom.Node Sheet = reader.load
>    ( new InputSource( new URL("file", "", args[1]).toString() ) );
>
> org.w3c.dom.Node Content = reader.load
>    ( new InputSource( new URL("file", "", args[0]).toString() ) );
>
> com.sun.xml.tree.XmlDocument doc = new com.sun.xml.tree.XmlDocument ();
>
> OutputMethodHandlerImpl outputMethodHandler = new OutputMethodHandlerImpl( null );
>
> //  This is important. For a servlet one should use:
> //  outputMethodHandler.setDestination ( new ServletDestination(response) );
>
> outputMethodHandler.setDestination ( new
FileDescriptorDestination(FileDescriptor.out) );
>
> reader.createTransform(Sheet).My_transform( Content, outputMethodHandler );
>
> Rgds.Paul.
>
> PS. If you realy need that hack very-very-much I may send it to you, but I suggest
> to wait until (if) James will come with the 'common'  design of XSLTransformEngine
> and XSLProcessorImpl .
>
>
>



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