cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: Suggestion for XHTMLSerializer
Date Tue, 09 Aug 2005 21:40:13 GMT
On 09.08.2005 02:03, Vadim Gritsenko wrote:

>   * Serializers are allowed to implement SitemapModelComponent
>   * SitemapModelComponent has setup method
>   * setup() method passes src parameter - src attribute from the sitemap.
> Now, from Cocoon design perspective, this is all legal and supported. 


>> That "well documented and understood option of the XSLT specification" 
>> was categorically rejected when designing Cocoon 2.x.
> Can you send a link to that?

Having the serializers implementing SitemapModelComponent happened not 
_that_ long ago: So there must 
have been reasons to do not so before.

>> Wouldn't something like a TRAXSerializer add side effects to the 
>> concept of sitemap serializers?
> What would be the side effects? It's harder to implement side effects in 
> XSLT than in custom Java serializer.

But Java is harder to write than XSLT. Many design decisions in Cocoon 
were made to heighten the barrier of abuse.

>> Introducing a trax serializer means that what you see in the sitemap 
>> serializer declaration is only *part* of what is output. There is a 
>> huge difference between the two, and I can see why Joerg was so upset.
>> * The svg2jpeg serializer always requires SVG input and always 
>> provides JPEG output -- including the mime type of image/jpeg.
>> * The fo2pdf serizalizer always requires XSL:FO input and always 
>> provides PDF output -- including the mime type of application/pdf.
> FOPSerializer capable of producing PDF, PS, PCL, and (IIRC) more.

Capable yes, but not deciding dynamically. The pipeline knows the result 
*before* the serializer has been executed, i.e. at setup time:

> That's good practice, which does not go away with adding new serializer.


> But I'd not call it best practice - as I mentioned previously.


> Having tools to do it does not mean you should do it. As they say, 
> "Closed course, professional driver. Don't try it at home".

I still don't see why we should add a component to the Cocoon codebase, 
where we know from the beginning that it is "not best practice" (better 
formulation than my "problematic", but meaning the same).


View raw message