Morten --
I think this is a HUGE step and one that will go far toward helping the
integration of the two "flavors" of XSLT processors. Now, even
simpletons like me will be able to find a way into understanding the
overall organization of XSLTC.
Good work!!
Gary
Morten Jorgensen wrote:
>
> Scott & all,
>
> I have modified our TrAX implementation in org.apache.xalan.xsltc.trax
> do reflect the design we came up with after our phone meeting a couple
> of days ago. Our TransformerFactoryImpl class is basically a stylesheet
> compiler. The definition for (ie. bytecodes) the translet class and all
> auxiliary classes are stored in the generated Templates objects. These
> are serializable and can be sent to any output stream and stored/cached
> similar to the way we now store *.class filed (one very positive side-
> effect here is that all class definitions needed for a single
> transformation is stored in one, single file). Calling newTransformer()
> on the Templates object is basically the same as instanciating the
> translet and auxiliary classes (the Templates object represents the
> translet definition, the Transformer object represents an instance).
>
> I've added a few files to our samples directory that illustrate how
> translets can be used through TrAX. A ran some very simple tests to
> compare TrAX compilations to regular XSL compilations, and there is
> 3% performance degradation, which I choose to quitely ignore.
>
> xml-xalan/java/samples/Compiled/JAXP/Transform.java
> xml-xalan/java/samples/Compiled/JAXP/Compile.java
>
> Do not try to run any extensive testing on the TrAX implementation.
> This is just a very basic start and proof of concept.
>
> Morten
