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
