cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
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: 
http://thread.gmane.org/gmane.text.xml.cocoon.devel/26621. 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: 
http://svn.apache.org/viewcvs.cgi/cocoon/blocks/fop/trunk/conf/fop.xmap?rev=179076&view=markup.

> 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).

Joerg

Mime
View raw message