Joerg Heinicke wrote:
On 08.08.2005 23:10, Vadim Gritsenko wrote:
XSLT serialization (as per spec Eric quoted) provides a way for "one
way 1:1 transformation" of xml into the desired view format exactly in
the same way as batik transforms svg into png. XSLT has more
capabilities, one even might say that it allows for arbitrary xml
transformations - but another will say that's exactly the
transformation he needs for his view.
From the pipeline's POV it's not 1:1 as the serializer decides to which
output format the XML is serialized, so it is 1:n, so the output is also
not predictable for the pipeline.
Output of the serializer is never predictable, otherwise no need for
/**
* Get the mime-type of the output of this <code>Component</code>.
*/
String getMimeType();
TraxSerializer does not force you to put your final view xslt
transform into the serializer. And I'd even discourage you to do it -
as it, in some scenarios, reduces possibilities of reuse - but in some
scenarios it'd be advantageous to add small xslt based serialization
instead of writing yet another java serializer.
Yes, I'm not forced to use TraxSerializer. Maybe I should withdraw from
this discussion because it leads to nearly nowhere. Let's just add this
component to Cocoon's codebase.
But IMO the codebase is already to big. There are so many components
based on problematic approaches (SourceWritingTransformer,
What would be the migration path? (beside flow).
DOMSessionTransformer (both with side effects))
You mean WriteDOMSessionTransformer? Should be deprecated, imho. Could be
replaced with SourceWritingTransformer and dom source, or some such.
And, just to make it clear, "side effects transformers" are not problematic.
They are not a best practice, so we don't generally recommend them, but it does
not mean they have no place. And some of such transformers have no replacement
at all.
or widely unused (why is
the TraxGenerator still in trunk after more than 2 years?).
<shrug> Some of the code is 5 or 6 years old. So what? </shrug>
It's in the scratchpad. Combined with TraxSerializer, they both can be part of
trax block.
Why shall we
add another component that's problematic (at least in my POV, see above)?
It does not have to be in the trunk (options - own block, wiki, bugzilla, sf,
external block). It does not have to be even added - but I don't see why not.
Vadim
