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.
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, DOMSessionTransformer (both with side effects)) or widely unused (why is the TraxGenerator still in trunk after more than 2 years?). Why shall we add another component that's problematic (at least in my POV, see above)?
Joerg
