>> I don't understand here. How could i modify a model with an xsl >> transformation (and by extension an xsl serialization) ? XSL is for >> generating views from a sax representation of a model (not to be confused >> with the model itself. It's generated at the beginning of the pipeline by >> the generator). As far as you don't write nasty java extension to your >> processor (do you really need xsl for nasty java ?), i don't see how you >> can achieve such side effects with xsl (ie writing to your DB which IS >> the model). > > Perhaps I overused the term "model". I was referring more to the > _Document_Object_ Model (DOM) represented by the various stages of the > SAX stream. A generator creates one DOM, a transformer converts that > DOM into another, and a serializer takes the DOM resulting from the > final transformer and creates a representation of it. It does not > modify that DOM. >
So now it's your turn to talk about implementation details ;-) Honestly i think you're wrong with that approach. The sitemap controller is a controller in the MVC world, and a un pipeline is kind of execution unit of that controller. It's said nowhere that you should not modify model or dom or whatever in the first stages of the pipeline and not in others stages. It's like you said that in the flow controller, you should not access the model after the first line or modify the dom after the third. If you look at the core components, no one follow such a hard constraint. Some serializers do radical transformation (svg2jpeg, links, ...), while some transformers only do very light transformation (encodeurl, i18n, ...). If you take the links serializer for example you will find that the output is radically different than the input (and this is a serializer). If you take the svg2jpeg serializer you will see that the ouput is just a "view" of the input, because apart the file format "radicalisation", a lot of information disappear during the convertion from vectors to bitmaps. So i could perfectly do a silly xsl serialization that only display the root tag name of the input (it still a view of my input) and call that a serialization. You see here that a serializer actually do a transformation. The only difference is that the resulting transformation always take the form of sax events in a transformer (eventually followed by some side affects: sql, xmldb, ...), and is a final transformation which could take many different forms with a serializer (binary, zip, text, jpeg, xml, ...). > > But the important thing is that using an XSLT internally is merely an > implementation detail. Exposing the XSLT implementation to users is > what Joerg and I take issue with. (Don't mean to speak for you here, > Joerg, correct me if I'm misquoting you.) > I'm not exposing the xslt implementation. There is other way of hiding implementation than compiling and encrypting a stylesheet in a java class. Users should not access the files of your webapp (this is webapp/container security), designers should not modify core stylesheets (this is repository security). > > Those are absolutely bugs that should be fixed in the current > serializer(s). Sure. It already works with xsl, it does not break any design pattern, it's maintained by others, fully tested and debugged on other projets, what else ? For all kind of text/xml/html serialization you have a lot simpler, more robust and more secure way of writing/extending/reusing serializers. Regards.
