cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From BURGHARD √Čric <eric.burgh...@systheo.com>
Subject Re: Suggestion for XHTMLSerializer
Date Sun, 07 Aug 2005 08:53:48 GMT
>> 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.


Mime
View raw message