cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From BURGHARD √Čric <>
Subject TraxSerializer implementation
Date Wed, 10 Aug 2005 13:03:50 GMT

I don't want to just start another thread on this already prolific subject
(was: Suggestion for XHTMLSerializer). Many interesting POV were explained,
and i think that the final idea is that the TraxSerializer simply allow you
to write your serializer in XSL (java seems to be the only possibility for
the moment).

I saw that many commiters are not against this idea, so it's sufficient for
me to submit the TraxSerializer and let the rules of the open source 'wild'
life decide for the future of this component.

I have here a traxserializer which works (since now, only used with saxon)
but it was made in a hurry just to quickly overcome various bugs of
standard serializers.

For simple cases, <map:serialize type="trax"/> is sufficient (no need of a
src attribute), because
1. the serialization works without stylesheet (it works then like the
XMLSerializer do, but with the ability to specify the serialization method)
2. you can provide a default stylesheet in the configuration bloc if you

So the configuration block of the component just take the exactly same
parameters than the standard XMLSerializer + a 'method' one (which is
hardcoded in XMLSerializer) + a 'stylesheet' one to provide a default

For other cases, you can use this form
<map:serialize type="trax" src="xhtml.xsl">
        <map:parameter name="agent" value="{request-header:User-Agent}"/>

I only kept the use-request-parameters param, because i never use session or
cookies in transformations and i thought it was sufficient. But should we
allow use-session-info and use-cookies too ? You already know that IMHO the
set of the transformers is a subset of the one of the serializers. That's
why, at least we should have the same expressiveness in TraxTransformer and
TraxSerializer. But perhaps these params were just a mistake for the
Transformer. I don't care in fact. Choose.

That's for the spec, here are the actual limitations
1. It use directly a transformer factory and cache the templates objects
(precompiled stylesheet) by it's own,
2. It does not include a single (but necessary) xalan fix for serialization,
3. It does not test if the choosen xslt-processor handle the serialization

So basicly, the refactoring targets are the use the XSLTProcessor for 1,
inheritance of AbstractTextSerializer for 2 and the adjunction of the
necessary test for 3.

The AbstractTextSerializer instantiate a transformer factory in the
configure method which will never be used (this is handled by the
XSLProcessor). I see 3 solutions here
a) accomodate ourselves of this 'instantiation for nothing',
b) override the configure method: a copy & paste minus the instantiation
part. but that mean that we change some private attribute to protected in
the AbstractTextSerializer,
c) separate somehow the configure and the instantiation in the
AbstractTextSerializer, so the TraxSerializer can just inherit silently,
d) Refactor the AbstractTextSerializer for using the XSLTProcessor instead
of the factory

I face a more complicated problem with the test (i think that every
xsltprocessor implement the serialize feature but who knows). I need an
access to the getFeature method of the TransformerFactory which is 'damn
well' encapsulated in the XSLTProcessor.
a) augment the XSLTProcessor interface to provide a getTransformerFactory
b) come back to 1a): afterall the instantiation is usefull for this test.

Be my advisers.


View raw message