You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Willie Wheeler <ww...@andrew.cmu.edu> on 2000/05/30 06:11:08 UTC
JSP vs. XSP
Hello all,
I have a question about the relative merits of JSP and XSP. 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. 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.
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. And that is a much weaker kind of inferiority, since it disappears once some server supports such functionality. Is this the kind of inferiority that people have in mind when they compare the two?
Willie
Re: JSP vs. XSP
Posted by Stefano Mazzocchi <st...@apache.org>.
Willie Wheeler wrote:
>
> Hi Stefano, all,
>
> Thanks for the excellent explanation of the technical difference.
You are welcome.
> I agree, supposing that the two technologies are otherwise more or less
> equivalent, that this difference alone makes XSP much more attractive.
Good.
> Following up a bit, why isn't this more commonly given as the crucial
> reason for adopting XSP over JSP?
It isn't? Well, it's a bug, then :)
> It doesn't seem that difficult to explain.
No, I don't think so.
> Most of what I have seen on the matter seems to say--falsely, we seem to
> agree (?)--that you can't separate content and presentation using JSP, and
> then goes on to give examples of poorly designed JSP pages (too much
> scripting, no JavaBeans, no custom tags, etc.).
You know, I designed JSP more than a year ago, well before JSP taglibs
and "model 2" patterns were discussed, proposed and standardized (I know
this because I'm part of JCP-52 that controls the JSP spec).
XSP were created to point out the weak points of JSP when more complex
serving models were used.
Over time, both JSP and XSP added taglibs and proposed better models for
page generation to avoid placing scripting directly inside the page.
Ricardo's SiLLy (Simple Logicsheet Language) language, IMO, will give
XSP a _big_ advantage over JSP taglibs in both ease of use and ease of
development.
Anyway, I admittedly change my view over the months. JSP started as a
political anti-ASP technology but it's become more and more useful with
the addition of better design patterns into the picture. Unfortunately,
core design issues like the one I outlined break JSP for XML operation
on the server side.
There is _no_ absolute way around this, unless you break back
compatibility. Something that Sun _does_not_ want to do.
I proposed Sun to adopt XSP for things that need server side processing
and keep JSP for stuff that does not. I was told splitting JSP is _NOT_
an option.
But they are, indeed, afraid of XSP power! They know their marketing
engine might not be as powerful as the power of our ideas. Your comments
seem to agree on that.
We are working on the new Servlet 2.3 model that should allow JSP to
output content using SAX events. This will happen probably 1Q2001. But,
to be quite honest, I can't predict the result of what's going on since
nothing resolving has been proposed yet.
I'm quite confident XSP will provide better solutions for XML because
_designed_ on XML for XML and with no back-compatibility issues.
> Or else the argument places
> undue emphasis on relatively minor syntactic issues such as not having to do
> this sort of (admittedly ugly) thing
>
> <% for (...) { %>
> Blah blah...
> <% } %>
>
> in XSP.
> Anyway, there's a not-so-subtle plea in there for any XSP evangelizers
> that might be listening. Thanks for the very useful explanation. :-)
Cocoon2 will implement XSP 2.0 which we are designing right now. I'll be
very happy if you could review it to tell us if we got the right pitch.
I'll keep you posted when the document is available. Thanks.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: JSP vs. XSP
Posted by Russell Castagnaro <ru...@synctank.com>.
Willie,
XSP hasn't been around quite as long for one.
But JSP IS easier to use for an html coder. Basically knowing a little
JavaScript prepares an html coder for basic JSP (sure there are some
differences), but fewer HTML folks understand XML/ XSL.
I prefer XSL/ XSP, but JSP is significantly easier to explain to a neophyte.
-rrc
Willie Wheeler wrote:
> Hi Stefano, all,
>
> Thanks for the excellent explanation of the technical difference. I
> agree, supposing that the two technologies are otherwise more or less
> equivalent, that this difference alone makes XSP much more attractive.
> Following up a bit, why isn't this more commonly given as the crucial
> reason for adopting XSP over JSP? It doesn't seem that difficult to explain.
> Most of what I have seen on the matter seems to say--falsely, we seem to
> agree (?)--that you can't separate content and presentation using JSP, and
> then goes on to give examples of poorly designed JSP pages (too much
> scripting, no JavaBeans, no custom tags, etc.). Or else the argument places
> undue emphasis on relatively minor syntactic issues such as not having to do
> this sort of (admittedly ugly) thing
>
> <% for (...) { %>
> Blah blah...
> <% } %>
>
> in XSP.
> Anyway, there's a not-so-subtle plea in there for any XSP evangelizers
> that might be listening. Thanks for the very useful explanation. :-)
>
> Willie
>
> ----- Original Message -----
> From: Stefano Mazzocchi <st...@apache.org>
> To: <co...@xml.apache.org>
> Sent: Tuesday, May 30, 2000 7:07 AM
> Subject: Re: JSP vs. XSP
>
> > > 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.
> > <st...@apache.org> Friedrich Nietzsche
> > --------------------------------------------------------------------
> > Missed us in Orlando? Make it up with ApacheCON Europe in London!
> > ------------------------- http://ApacheCon.Com ---------------------
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> > For additional commands, e-mail: cocoon-users-help@xml.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
--
Hope to see you at my presentation, "Making the Most of XML, XSL and Server-Side
Processing"
at XML DevCon 2000, June 25-28, 2000.
Russell Castagnaro
Chief Mentor
SyncTank Solutions
http://www.synctank.com
Earth is the cradle of mankind; one does not remain in the cradle forever
-Tsiolkovsky
Re: It's early but it's coming...
Posted by Mark Washeim <es...@canuck.com>.
on 31/5/00 11:01 am, Jari Aarniala at jari.aarniala@ioboxgroup.com wrote:
> ----- Original Message -----
> From: Mark Washeim <es...@canuck.com>
> To: <co...@xml.apache.org>
> Sent: Tuesday, May 30, 2000 10:27 PM
> Subject: It's early but it's coming...
>
>
> : Hej, all. Ok, this is a tease, but it's going to be pretty bloody hot in
> the
> : kitchen soon, soooooo....
> :
> : http://195.42.213.219/editorial/toctraverse.xml?lang=gb&toc=1
> :
> : That's www.eurofootball.com, just the data, no pretty stuff...
>
> This is the same site I´ve seen heavily advertised on MTV? Geez, good luck!
>
> Jari
Yeah, told you it was going to get hot in the kitchen. Sigh....
--
Mark (Poetaster) Washeim
'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.
Quem colorem habet sapientia?'
Evan S. Connell
Re: AW: AW: It's early but it's coming...
Posted by Mark Washeim <es...@canuck.com>.
on 31/5/00 12:26 pm, Matthew Langham at mlangham@sundn.de wrote:
>>>>
>>
>> Looks good :-). How does the Cocoon generated stuff tie in to the "glossy"
>> part (www.eurofootball.com)? How many "hits" are you expecting Cocoon to
>> handle?
>>
>
> The glossy part is just the finished XSL/HTML. I'm adapting that
> (www.eurofootball.com) xsl currently to work with the final data structs....
>
> We're expecting upwards of 50,000 user sessions a day during Euro 2000
> <<<
>
> 50,001 :-)
>
> What hardware is it running on? Which web-server are you using?
>
> Matthew
2 (3) Enterprise 250s, 2 processor, 1 gb ram each, IBMHTTPd( AKA, Apache
1.3.6), WebSphere 2.0
--
Mark (Poetaster) Washeim
'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.
Quem colorem habet sapientia?'
Evan S. Connell
AW: AW: It's early but it's coming...
Posted by Matthew Langham <ml...@sundn.de>.
>>>
>
> Looks good :-). How does the Cocoon generated stuff tie in to the "glossy"
> part (www.eurofootball.com)? How many "hits" are you expecting Cocoon to
> handle?
>
The glossy part is just the finished XSL/HTML. I'm adapting that
(www.eurofootball.com) xsl currently to work with the final data structs....
We're expecting upwards of 50,000 user sessions a day during Euro 2000
<<<
50,001 :-)
What hardware is it running on? Which web-server are you using?
Matthew
--
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel: +49-5251-1581-30 [mlangham@sundn.de - http://www.sundn.de]
=================================================================
------------------------------------------------------------------------------------------
...this mail was scanned for viruses by mailserver...
Re: AW: It's early but it's coming...
Posted by Mark Washeim <es...@canuck.com>.
on 31/5/00 11:39 am, Matthew Langham at mlangham@sundn.de wrote:
> : Hej, all. Ok, this is a tease, but it's going to be pretty bloody hot in
> the
> : kitchen soon, soooooo....
> :
> : http://195.42.213.219/editorial/toctraverse.xml?lang=gb&toc=1
> :
> : That's www.eurofootball.com, just the data, no pretty stuff...
>
> Looks good :-). How does the Cocoon generated stuff tie in to the "glossy"
> part (www.eurofootball.com)? How many "hits" are you expecting Cocoon to
> handle?
>
The glossy part is just the finished XSL/HTML. I'm adapting that
(www.eurofootball.com) xsl currently to work with the final data structs....
We're expecting upwards of 50,000 user sessions a day during Euro 2000
--
Mark (Poetaster) Washeim
'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.
Quem colorem habet sapientia?'
Evan S. Connell
AW: It's early but it's coming...
Posted by Matthew Langham <ml...@sundn.de>.
: Hej, all. Ok, this is a tease, but it's going to be pretty bloody hot in
the
: kitchen soon, soooooo....
:
: http://195.42.213.219/editorial/toctraverse.xml?lang=gb&toc=1
:
: That's www.eurofootball.com, just the data, no pretty stuff...
Looks good :-). How does the Cocoon generated stuff tie in to the "glossy"
part (www.eurofootball.com)? How many "hits" are you expecting Cocoon to
handle?
Matthew
--
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel: +49-5251-1581-30 [mlangham@sundn.de - http://www.sundn.de]
=================================================================
------------------------------------------------------------------------------------------
...this mail was scanned for viruses by mailserver...
Re: It's early but it's coming...
Posted by Jari Aarniala <ja...@ioboxgroup.com>.
----- Original Message -----
From: Mark Washeim <es...@canuck.com>
To: <co...@xml.apache.org>
Sent: Tuesday, May 30, 2000 10:27 PM
Subject: It's early but it's coming...
: Hej, all. Ok, this is a tease, but it's going to be pretty bloody hot in
the
: kitchen soon, soooooo....
:
: http://195.42.213.219/editorial/toctraverse.xml?lang=gb&toc=1
:
: That's www.eurofootball.com, just the data, no pretty stuff...
This is the same site I´ve seen heavily advertised on MTV? Geez, good luck!
Jari
Re: It's early but it's coming...
Posted by sudhi <su...@planet.net>.
One thing I noticed was, If I dont accept cookies, language defaults to
english.
FYI
By the way, how do u fetch different language pages ?
Did u write ur own producer ?
~S
Berin Loritsch wrote:
>
> Any hints on optimizations? Granted it isn't being hit hard, but It's hard
> to come by processing times like you have on the test site.
>
> Also, what kind of hardware is this thing running on?
>
> Mark Washeim wrote:
>
> > on 30/5/00 10:21 pm, Berin Loritsch at bloritsch@infoplanning.com wrote:
> >
> > > Looks pretty good. Hopefully the skin you are working on won't use nested
> > > tables--they make the site feel slow (although the average server side
> > > processing
> > > was impressively quick).
> > >
> > > Mark Washeim wrote:
> > >
> >
> > Sadly, the HTML requires a certain amount of table nesting. I wish it had
> > been done using css and, perhaps dhtml, but, it's been a very driven project
> > (38 projects for the same client with a staff of 15)...
> >
> > I'm working on skinning it, but, you can see what it will be like at :
> > http://www.eurofootball.com
> >
> > That site is generated using xalan and xerces and a very poorly designed
> > servlet (data is the same)....
> >
> > --
> > Mark (Poetaster) Washeim
> >
> > 'On the linen wrappings of certain mummified remains
> > found near the Etrurian coast are invaluable writings
> > that await translation.
> >
> > Quem colorem habet sapientia?'
> >
> > Evan S. Connell
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> > For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
Re: It's early but it's coming...
Posted by Mark Washeim <es...@canuck.com>.
on 30/5/00 10:48 pm, Berin Loritsch at bloritsch@infoplanning.com wrote:
> Any hints on optimizations? Granted it isn't being hit hard, but It's hard
> to come by processing times like you have on the test site.
>
> Also, what kind of hardware is this thing running on?
>
> Mark Washeim wrote:
>
Smile. The framework itself is 'optimising'. Believe it or not, there is a
tremendous amount of file io going which, in java applications, is often
deadly. (There are at least 7 documents required per page instance !). The
reliance on documents was dictated by the document management system (called
easy update).
Smile. The second optimization IS the hardware.
Sun Enterprise 250, 2 processors, 1 gb RAM, 120 gb disk array.
Running IBMs apache (1.3.6 ++++)
and WebSphere (sadly, version 2)
WebSphere is really not being utilized as it should though.
I have to emphasise that, under load, we'll be very dependant on the
performance of the object cache.
Currently what you're looking at is a single XSP page acting as a 'template'
into which documents are populated. A custom logicsheet is being used (as
well as the Util and Request).
...
--
Mark (Poetaster) Washeim
'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.
Quem colorem habet sapientia?'
Evan S. Connell
Re: It's early but it's coming...
Posted by Berin Loritsch <bl...@infoplanning.com>.
Any hints on optimizations? Granted it isn't being hit hard, but It's hard
to come by processing times like you have on the test site.
Also, what kind of hardware is this thing running on?
Mark Washeim wrote:
> on 30/5/00 10:21 pm, Berin Loritsch at bloritsch@infoplanning.com wrote:
>
> > Looks pretty good. Hopefully the skin you are working on won't use nested
> > tables--they make the site feel slow (although the average server side
> > processing
> > was impressively quick).
> >
> > Mark Washeim wrote:
> >
>
> Sadly, the HTML requires a certain amount of table nesting. I wish it had
> been done using css and, perhaps dhtml, but, it's been a very driven project
> (38 projects for the same client with a staff of 15)...
>
> I'm working on skinning it, but, you can see what it will be like at :
> http://www.eurofootball.com
>
> That site is generated using xalan and xerces and a very poorly designed
> servlet (data is the same)....
>
> --
> Mark (Poetaster) Washeim
>
> 'On the linen wrappings of certain mummified remains
> found near the Etrurian coast are invaluable writings
> that await translation.
>
> Quem colorem habet sapientia?'
>
> Evan S. Connell
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
Re: It's early but it's coming...
Posted by Mark Washeim <es...@canuck.com>.
on 30/5/00 10:21 pm, Berin Loritsch at bloritsch@infoplanning.com wrote:
> Looks pretty good. Hopefully the skin you are working on won't use nested
> tables--they make the site feel slow (although the average server side
> processing
> was impressively quick).
>
> Mark Washeim wrote:
>
Sadly, the HTML requires a certain amount of table nesting. I wish it had
been done using css and, perhaps dhtml, but, it's been a very driven project
(38 projects for the same client with a staff of 15)...
I'm working on skinning it, but, you can see what it will be like at :
http://www.eurofootball.com
That site is generated using xalan and xerces and a very poorly designed
servlet (data is the same)....
--
Mark (Poetaster) Washeim
'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.
Quem colorem habet sapientia?'
Evan S. Connell
Re: It's early but it's coming...
Posted by Berin Loritsch <bl...@infoplanning.com>.
Looks pretty good. Hopefully the skin you are working on won't use nested
tables--they make the site feel slow (although the average server side
processing
was impressively quick).
Mark Washeim wrote:
> Hej, all. Ok, this is a tease, but it's going to be pretty bloody hot in the
> kitchen soon, soooooo....
>
> http://195.42.213.219/editorial/toctraverse.xml?lang=gb&toc=1
>
> That's www.eurofootball.com, just the data, no pretty stuff...
>
> I'm still adding in some sql taglib driven pages.
>
> To give you some idea of what this will amount to:
> we expect up to 100,000 visitors every day during Euro 2000.
>
> sigh. well, so far so good. I'm probably going to be flooding you guys with
> optimization questions, shortly. :)
>
> By the weekend, it'll have it's skin (ie, look like www.eurofootball.com)
>
> Wish us luck :)
>
> --
> Mark (Poetaster) Washeim
>
> 'On the linen wrappings of certain mummified remains
> found near the Etrurian coast are invaluable writings
> that await translation.
>
> Quem colorem habet sapientia?'
>
> Evan S. Connell
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
RE: It's early but it's coming...
Posted by JJD <jj...@home.com>.
Hi Mark Washeim: You got my best wishes. I only wish I was in your team at
present, but perhaps another time. Till later JJD (from NJ)
-----Original Message-----
From: Mark Washeim [mailto:esalon@canuck.com]
Sent: Tuesday, May 30, 2000 3:28 PM
To: cocoon-users@xml.apache.org
Subject: It's early but it's coming...
Hej, all. Ok, this is a tease, but it's going to be pretty bloody hot in the
kitchen soon, soooooo....
http://195.42.213.219/editorial/toctraverse.xml?lang=gb&toc=1
That's www.eurofootball.com, just the data, no pretty stuff...
I'm still adding in some sql taglib driven pages.
To give you some idea of what this will amount to:
we expect up to 100,000 visitors every day during Euro 2000.
sigh. well, so far so good. I'm probably going to be flooding you guys with
optimization questions, shortly. :)
By the weekend, it'll have it's skin (ie, look like www.eurofootball.com)
Wish us luck :)
--
Mark (Poetaster) Washeim
'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.
Quem colorem habet sapientia?'
Evan S. Connell
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
It's early but it's coming...
Posted by Mark Washeim <es...@canuck.com>.
Hej, all. Ok, this is a tease, but it's going to be pretty bloody hot in the
kitchen soon, soooooo....
http://195.42.213.219/editorial/toctraverse.xml?lang=gb&toc=1
That's www.eurofootball.com, just the data, no pretty stuff...
I'm still adding in some sql taglib driven pages.
To give you some idea of what this will amount to:
we expect up to 100,000 visitors every day during Euro 2000.
sigh. well, so far so good. I'm probably going to be flooding you guys with
optimization questions, shortly. :)
By the weekend, it'll have it's skin (ie, look like www.eurofootball.com)
Wish us luck :)
--
Mark (Poetaster) Washeim
'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.
Quem colorem habet sapientia?'
Evan S. Connell
Re: JSP vs. XSP
Posted by Willie Wheeler <ww...@andrew.cmu.edu>.
Hi Stefano, all,
Thanks for the excellent explanation of the technical difference. I
agree, supposing that the two technologies are otherwise more or less
equivalent, that this difference alone makes XSP much more attractive.
Following up a bit, why isn't this more commonly given as the crucial
reason for adopting XSP over JSP? It doesn't seem that difficult to explain.
Most of what I have seen on the matter seems to say--falsely, we seem to
agree (?)--that you can't separate content and presentation using JSP, and
then goes on to give examples of poorly designed JSP pages (too much
scripting, no JavaBeans, no custom tags, etc.). Or else the argument places
undue emphasis on relatively minor syntactic issues such as not having to do
this sort of (admittedly ugly) thing
<% for (...) { %>
Blah blah...
<% } %>
in XSP.
Anyway, there's a not-so-subtle plea in there for any XSP evangelizers
that might be listening. Thanks for the very useful explanation. :-)
Willie
----- Original Message -----
From: Stefano Mazzocchi <st...@apache.org>
To: <co...@xml.apache.org>
Sent: Tuesday, May 30, 2000 7:07 AM
Subject: Re: JSP vs. XSP
> > 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.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
> Missed us in Orlando? Make it up with ApacheCON Europe in London!
> ------------------------- http://ApacheCon.Com ---------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
>
Re: JSP vs. XSP
Posted by Stefano Mazzocchi <st...@apache.org>.
> 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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------