cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: JSP vs. XSP
Date Tue, 30 May 2000 11:07:23 GMT
> Willie Wheeler wrote:
> 
> Hello all,
> 
>     I have a question about the relative merits of JSP and XSP.

ok

> Recently I've read explanations to the effect that XSP is better
> because (1) JSP does not really separate content from presentation,
> whereas XSP does, and (2) you can't (easily?) do server-side XSLT on
> JSP output, whereas you can easily do so with XSP output. 

The above are not entirely correct. see below

> I've seen
> only very summary versions of the arguments, so perhaps I am about
> to mischaracterize them, but the argument for (1) seems to be premised
> on the idea that JSP output must be HTML. This is certainly false; one
> can easily serve XML from a JSP, and one can put presentation code in
> an XSL stylesheet for client-side processing.

Correct. The problem comes out on the server side since JSP assume that
you have a stream channel for output, this requires you parse the JSP
output, while for XSP, we generate SAX events directly and avoid the
overhead of the parser.

This is the most significant technical difference (along with
XML-friendlyness as a whole) but reflects both performance and server
side operativity.

>     Regarding (2), it seems to me that if there is no easy way to
> apply server-side XSLT to a JSP after the JSP engine has compiled
> it, and there is an easy way to do so with XSP, then, everything else
> being equal, JSP is clearly an inferior technology--I don't want to
> have to depend on clients to do their own XSLT processing! But these
> considerations wouldn't make JSP *inherently* inferior, just inferior
> because there aren't any servers that allow you to specify that .jsp
> files should be processed first by the JSP engine and secondly by the
> XSLT processor. 

I disagree. JSP _are_ inherently inferior by design (as servlets are)
since they don't allow for anything by chars and bytes to be generated
on the output channels.

> And that is a much weaker kind of inferiority, since
> it disappears once some server supports such functionality. 

Have you ever tried to do it? Well, no matter how brilliant you are
writing the JSP compilation engine, the JSP _require_ that the output
stream be available to your JSP logic. So, you simply do 

  output.println("<hello/>");

and you require a parser after that.

JSP can't simply match XSP because of design flaws.

> Is this
> the kind of inferiority that people have in mind when they compare the
> two?

No, it's much deeper and goes to the very heart of the technology. This
is why so many are switching from JSP to XSP when dealing with content
that needs server side post-processing.

Note: other then this, XSP and JSP are pretty much equivalent even if I
personally don't like their un-nestable markup syntax which make mixing
content and logic a lot harder... but that's just personal taste and
doesn't count as a technical argument.

Note2: when the taglib language will be implemented, XSP will be
incredibly superior of JSP, even on the taglib side of things.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message