cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted" <...@gs2admin1.e-meet.com>
Subject Re: Happy to be wrong!
Date Fri, 28 Jan 2000 15:24:56 GMT
Stefano, if I may take a stab at this from a different point of view?

Cocoon's raison d'etre is as a Web Publishing Framework. I think as
developers, we tend to forget this, and we are pushing Cocoon to be an
Application Development Framework. A clear example of this is the xBugs
proposal, which is an app. I am not saying that it can't be an app dev
framework (au contraire, I think it can develop into a kick-ass one).

These two directions have different needs. Publishing is more
output-oriented from a user's point of view, and therefore, the E-XSLT
direction makes sense. You can have:

XML -->(Whatever transformation you want, XSLT, E-XSLT)---->XML


App Dev, on the other hand, has a balance of input and output from a
user's point of view. I think, here is were Ricardo's taglibs make
sense, for the App Developer. You can have:

XML1 Input -->servlet-->Dynamically-generated XML0 (using classic XSP or
via taglibs in XSL) -->XSLT-->XML1 Output

XML1 can be WML, VML, XHTML or whatever. Groups can contribute taglibs
for this cause, which become lego blocks of the app dev framework (SQL,
Mail, etc).

Each seem to have its own place, but within its own framework ---
publishing or app dev. I agree with Pier. It may take a while to marry
them, but they can be married.

Ted
Chaos has bifurcated.


Stefano Mazzocchi wrote:
> 
> Have you ever been happy to be wrong?
> 
> Of course, not always, but sometimes it feels good to see something that
> you were missing before and understanding that doing this you saved lots
> of pain and wasted resources.
> 
> Federico and I went to dinner out tonight and we came to the conclusion
> than the XSP specification can be _totally_ represented as an
> Extended-XSLT taglib. Nothing of what I've previously said is true: you
> gain nothing by using XSP.
> 
> The problem I had was driven by the "stylesheet compilation" idea. I'll
> will explain shortly why I think this is misleading and I will also
> explain this in a moment.
> 
> As you all know, the XSP idea came after seeing lots of holes in JSP
> support for XML. This doesn't go away. JSP cannot be used inside Cocoon
> and this won't change soon.
> 
> Ok, let's move on: this is the XSP model how I imagined it
> 
>  XML -XSLT-> XSP -something-> Java -javac-> Class -execution-> XML
> 
> Ricardo added something and this is how it's done today
> 
>  XML -XSLT-taglibs-> XSP -XSLT-> java -javac-> producer -execution-> XML
> 
> Many proposed the use of E-XSLT to do the same thing... my concerns
> where due mainly to performance reasons but they went away... let'
> see... you suggest to do something like this
> 
>  XML -EXSLT-> XML
> 
> as you see, there is a topological equivalence between the two, being
> the XSP model, a way to express how an E-XSLT engine should work
> internally. This was not clear when I designed XSP since it was Ricardo
> that added the namespace-taglib driven idea to the XSP spec. This
> completely changed the picture.
> 
> The only concern I had, was still performance: how can EXSLT work faster
> than a compiled server page? simple, it can't.
> 
> Scott proposed stylesheet compilation as a solution: but in my mind I
> could not see how compiling a stylesheet would help... true, you could
> simplify many things and do faster transformations but you still had to
> do XML parsing, events feeding, tree creation and evaluation and a bunch
> of stuff...
> 
> Tonight, Federico opened my eyes (man, I'll miss that guy! these
> exoffice mean men are stealing all my friends, damn it! :)
> 
> A smart E-XSLT engine should _not_ perform stylesheet compilation (which
> may be helpful but no that much), but do _page_ compilation. Let's look
> again:
> 
>  XML -EXSLT-> Java -javac-> producer -execution-> XML
> 
> so, if we evaluate the two with what Cocoon does today we get
> 
>  -EXSLT-> := -XSLT-taglibs-> XSP -XSLT->
> 
> which makes XSP totally useless since it's just a step between XSLT
> transformations.
> 
> QED :)
> 
> NOTE: I still like the ability to use XSP as a taglib for direct code
> inclusion inside a page, it may be helpful.
> 
> Anyway, I'll happily let Ricardo and all you other XSLT experts figure
> out the way to make the above possible, but I've been finally convinced
> and I'm a happy guy now :)
> 
> --
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <stefano@apache.org>                             Friedrich Nietzsche
> --------------------------------------------------------------------
>  Come to the first official Apache Software Foundation Conference!
> ------------------------- http://ApacheCon.Com ---------------------

Mime
View raw message