cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: XSP (minus Cocoon plus SAX) success story
Date Thu, 27 Jan 2000 22:13:49 GMT
Mike Williams wrote:
>   >>> On Wed, 26 Jan 2000 12:58:58 +0100,
>   >>> "Stefano" == Stefano Mazzocchi <> wrote:
>   Stefano> Ehmmm, not to rain on the parade, but what's the point of doing
>   Stefano> this?
> Well, for a start, it's better than what I was doing before :-)

"1 - 0" for you :)
>   Stefano> You use XSP to compile your page into a java class. I presume this class
>   Stefano> is not a cocoon producer, so it must be a servlet or a class called by
>   Stefano> servlet, right?
> Right.  Called by a servlet, which passes in a Map of data.

>   Stefano> This class interprets some data and spits SAX events that get formatted
>   Stefano> in HTML. No cache, no post processing, nothing.
> No caching, but I do perform some post-processing.  Mainly to re-write
> URLs, at the moment.

Ok, this may change the picture, then.
>   Stefano> Why do you care spitting SAX events if nobody is processing them rather
>   Stefano> than the formatter? just output HTML and you're done.
> Could do, but then I'd have to HTML-quote stuff, and so on.  Existing XHTML
> Formatters already do a nice job of this.

Sure, there are also tools like ECS that do a magnificent job on this
>   Stefano> Ok, so, what have we got here? JSP with another syntax. A quick and
>   Stefano> dirty way of doing the same thing without any Cocoon code
>   Stefano>  XSP -> (xslt) -> JSP -> tomcat -> HTML
> Hmm, that's an interesting idea that hadn't occurred to me.
> I'm not quite sure what I'd gain, though.  Currently, the things I'm
> producing using XSP are page-templates, ie. just presentation.  All my
> control logic is in servlets (with business-logic and data-access in EJB),
> the idea being that a given page-template can be re-used by a number of
> different servlets.
> JSP mixes the control and presentation code into one file, though I guess I
> could have my servlets dump stuff in the request-attributes, and use JSP
> just for presentation.  But then the question remains, why is
>     XSP -> (xslt) -> JSP -> (compile) -> Java -> (compile) -> class
> any better than
>     XSP -> (xslt) -> Java -> (compile) -> class

I thank you for this :) since you think that XSP will live long and
prosper, but others believe that JSP has a much longer life...
expecially now that both XSP and JSP are converging under the wings of

>   Stefano> NOTE: I base this elaboration on your message, so I might well miss a
>   Stefano> very significant point, please tell me if it is so.
> Er, I'll let you be the judge of that.

Simply put: what you do could be done with carefully written JSP or with
a special XML DTD translated into JSP.

XSP were designed to fill the holes that you are avoiding yourself, so
not much point to use them unless you like XSP syntax more.

And if this is the case... I'm happy because I think JSP syntax sucks
too :)

Just wanted to point out that the 10-times peformance increase was not
due to the XSP model, but to the more general compiled server pages
model. Little difference, I agree, but it's easy to blind people with
such figures.

I find myself in the strange situation where XSP is something in between
JSP and E-XSLT....

if you know calculus enough, when three continuous functions

 f(x) <= g(x) <= h(x) for every 'x'


  lim    f(x) = lim    h(x)
  x->inf        x->inf

what happens to g(x)?

That's how I feel XSP right now: a little squeezed between two big guys

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------

View raw message