cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Re: Suggestion for XHTMLSerializer
Date Tue, 09 Aug 2005 00:17:55 GMT
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

Mime
View raw message