Jerome Louvel wrote:
Hi Marc and Joe,
I've extracted some of your writings into the existing RFE:
"Refactor TransformRepresentation"
http://restlet.tigris.org/issues/show_bug.cgi?id=377
and into a new RFE:
"Support DomSource, SaxSource and StreamSource"
http://restlet.tigris.org/issues/show_bug.cgi?id=390
Let's try to continue the discussion via the comments system maybe.
Jerome,
thx for this, I do think there is more stuff that needs to happen, I'm
just not sure yet about the whole approach.
* I need to have a second look and provide a test case, but the IMHO
clear remaining short-term 'issue' to solve in the current transformer
is the getTransformer() method that is currently keeping a lazy
initialized transformer object to reuse.
Since Transformer is not threadsafe this is not wise. I think this
should be changed to keeping a Templates object from which we keep
cloning distinct and separate Transformer instances (for one-time use)
However, I feel we need more then just fixes, even the term
'refactoring' seems to do injustice to how I think this should be
approached.
I haven't thought this trough completely, but my feeling is that
1/ xml transformations are bigger then only xslt, a more elaborate way
to transforming "Representations of mime-type text/xml" is needed IMHO.
It should cater for pipelines, multi-output, tracing and debugging,
logging, xml-api mismatch handling to cover sax/dom/stax/, etc
2/ I'm quite uncomfortable with the concept of the current
TransformerRepresentation.
* It having a pointer to the xml input source feels very unnatural: an
xslt sheet is to be seen as a generic xml transformation program that
can be executed on various xml inputs.
* In essence we talk about things that transmogrify (calvin and hobbes!)
representations, sure they themselves could be referenced, and 'get'
from a resource (as a representation) but from there I think an active
component is built that by itself is not a representation nor a
resource, no?
3/ from my experience with Cocoon (see a related hindsight design
evaluation here:
http://marc.info/?l=xml-cocoon-dev&m=113385491027675&w=2) I'm also
convinced there must be a clear separation between the
xml-transformation component and the restlet API.
My suggestion would be to
- either ambitiously define and build a (or pragmatically find an
existing) fairly generic and decent XML-manipulation system that can
work in streaming mode (sax and/or stax) and incorporate xslt (xslt2 maybe)
- and most importantly: lives in its own right *and* has clear hooks to
allow "execution contexts" to allow for pluggable defined 'parameters'
and uri-resolving
- only then fit in that beast into restlet:
- by providing a tied in transform-context implementation
- by defining uri-syntaxes that translate into building up
transformation machinery
Well above is only opinion, if more people feel any of the above makes
sense the continued dialogue should get us into an actual plan.
regards,
-marc=
