Dan,
I agree with your issues regarding JSP. Whilst JSP favours the UI designer
rather than the developer to some extent, the UI designer still needs some
knowledge of the Java language, an issue which I think is better solved by
using XML. OK, both JSP and XSL require use of some simple scripting
constructs, but with XSL you can achieve COMPLETE separation from your Java
code - no beans, nothing. Although Sun's "Application Programming Model"
advocates JSP over servlets I still don't buy it as much more than an
"anything you can do we can do too" to Microsoft's ASP. Your suggestion of
using XML/XSL validates the work I have been doing, however I have jumped
straight to the suggestion you make in your "disadvantages" section, and my
plan is to generate XML directly within any services which my servlets would
make use of.
Of course, there is a performance hit involved in performing the XSL
transformation, so if possible I would prefer not to add in the
servlet-to-JSP request dispatching process. Certainly, I expext to see
significant improvements in XML/XSL processing performance as newer
processers and parsers are released, and long term some of this burden
should be moved onto the client anyway (at least for web browser clients).
IMHO, going the XML route produces a more versatile, more architecturally
sound web application than the Model 2 approach of throwing unnecessary
layers into the pot just for the sake of it. The fact that an XML-enabled
servlet can return an untransformed XML document means that you could then
"front-end" your data services with an XML-over-HTTP servlet (SOAP anyone?),
and open them up to a very wide range of clients if desired. This will be
even more versatile when we have a Java-to-XML data binding.
Unfortunately, I suspect that because XML/XSL is at a slight disadvantage to
JSP in the maturity stakes, and because Sun themselves advocate JSP, Model 2
will take over. I take some satisfaction from the fact that I am not alone
in my concerns regarding Model 2 - all of the Technical Architects and
developers with whom I have discussed it are uncomfortable with the idea.
But I also have concerns that because of this people might choose to go with
JSP alone and start using the JSP as both a controller and a view, packing
the code that would be in the servlet in a Model 2 design into the JSP and
thus losing the separation of the presentation code. The result - a
situation no better than that which we have with servlets.
As for a name, how about "XServlet"...!?
Regards,
Stephen Baishya
Technical Architecture Designer
Britannia Building Society
UK
-----Original Message-----
From: A mailing list about Java Server Pages specification and reference
[mailto:[EMAIL PROTECTED]]On Behalf Of Daniel Lopez
Sent: 08 May 2000 08:06
To: [EMAIL PROTECTED]
Subject: Model 3 Architecture
Hi,
Some people asked my about this "Model 3" I talked about in my last
posting about "model 2 servlet mapping question" so I thought I should
explain what I meant, not to confuse people. First, before people starts
asking about specifications and documentation, it's by no means an
official name and AFAIK it hasn't been mentioned anywhere. It's just an
idea several people in this list seem to be using and I just have to
give it a short name so... my apologies if this drrove someone to
confusion. Explanation follows:
...
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
