cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Muench" <smue...@us.oracle.com>
Subject Re: Happy to be wrong!
Date Fri, 28 Jan 2000 18:29:06 GMT
Like XSP "tags" any/all XSLT extensions elements can:

  (*) Optionally do arbitrary processing
  (*) Optionally write something to result page

This is a pretty open-ended model that doesn't
pin you into publishing versus app development.

you might argue that in the appdevelopment
scenario the "arbitrary processing part" 
plays a bigger role, perhaps writing nothing
into the result page, but any combination is
possible.

_________________________________________________________
Steve Muench, Consulting Product Manager & XML Evangelist
Business Components for Java Development Team
http://technet.oracle.com/tech/java
http://technet.oracle.com/tech/xml
----- Original Message ----- 
From: "Ted" <ted@gs2admin1.e-meet.com>
To: <cocoon-dev@xml.apache.org>
Sent: Friday, January 28, 2000 7:24 AM
Subject: Re: Happy to be wrong!


| 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