cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: JSP vs. XSP
Date Thu, 01 Jun 2000 16:20:39 GMT
This is debate is extremely relevant to the project I'm currently 
working on... Basically, XSP does things right, it does it well, and 
far better than JSP in its current form, but the fact that it isn't a 
standard adopted by Sun makes it hard for big organisations to adopt 
them for large scale project.

I had a look at the JSP 1.1 spec last night, and the fact that the 
xml-compliant JSP markup it defines looks extremely similar to the XSP 
markup, and its admittance of its lack of support for XSLT to be 
remedied in future specs, would suggest that JSP will have to 
incorporate XSP at some point, albeit in a different guise - cue dreams 
of a few search and replace regexps to upgrade my pages to future JSP 
specs that handle server side processing :-).

I read a message yesterday from tomcat-dev, which 
suggests that the development of the next JSP spec will take a keen 
look at XSP, and bearing in mind the existing associations with Sun in 
the form of Jakarta, maybe we could press home to Sun the need for 
this! I think that it would definitely help the take-up of XSP, and by 
association Cocoon, if some official statements on this subject were to 
come into being. As an aside, has anyone played around with Resin and 
have anything to say on its XTP, which seems to be just XSP under a 
different name, and also another reason for JSP to head in this 


> -----Original Message-----
> From: stefano 
> Sent: 30 May 2000 22:52
> To: cocoon-users
> Cc: stefano
> Subject: FW: Re: JSP vs. XSP
> 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.
> <>                             Friedrich Nietzsche
> --------------------------------------------------------------------
>  Missed us in Orlando? Make it up with ApacheCON Europe in London!
> ------------------------- http://ApacheCon.Com ---------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

View raw message