Hi Stephen,
Comments intermixed :)
Stephen Baishya wrote:
>
> 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.
And don't forget that XML and XSL are language independent with all the
implied benefits.
> 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.
I agree that JSP is not a one-size-fits-all solution and that it might
have been done better in some aspects. But I still think it has its
place and, as any other tool, you just have to learn when/how to use it
appropriately.
> 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.
We are still going to use JSP to generate XML from Java because it fits
pretty well into out previous model 2 architecture and because getting
from a static XML document to a dynamic one is easier with a JSP page
than within a servlet. And then you also have your "XML formatting"
independent of your action classes, thus having a cleaner separation
which means ease of maintenance, reusability...
> 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).
We also try not to add the extra layer, hence the PLSQL approach, but as
long as the architecture remains easy to develop and mantain. As long
as no xml-java mapping is there, JSP seems to be a good option. We still
have to test thoroughly whether it's worthy or not, but we think
generating XML directly from the servlets is, right now, too messy. And
we don't consider, right now, moving the XSL parsing to the client. Why
send both documents XML & XSLT to the client if you already now in the
server what you have to do with them? You would be wasting network
bandwidth and relying in browsers compatibility and those are not good
things.
> 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.
If we had such a binding, I agree we might try to take advantage of it
but, IMHO, using JSP doesn't mean adding such a thick layer. It's just a
servlet anyway and we use for business logic vs results formatting
independence. I agree too many layers might spoil your cake, so we try
to use the ones we find worthy. But you might also use WebMacro(I
haven't tested, just a guess) or other similar approaches for the
generation of the XML.
> 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.
I would say that XML/XSL is in a slight disadvantage regarding the
maturity of the tools, not the technology itself. Standard taglibs are
not there yet and having a tool that can do everything, even allow
people to create the ugliest JSP pages with more Java than HTML, doesn't
mean, for me, being mature. If all these efforts of creating drag & drop
JSP(HTML) tools were directed towards developing visual XML&XSL tools,
which are language/container/taglib independent we would get, IMHO, much
better results.
> 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.
Agreed! If I had to come up with a set of taglibs that I would like to
add to JSP. I would basically come up with what XLS gives you as I don't
think that sending mails, connecting to the DB, retrieving/sending
files... belong to a JSP page. But having this possibility doesn't mean
you have to use it. I agree though, that many people are tempted to
follow the shortest, usually dirtiest path.
> As for a name, how about "XServlet"...!?
Ummm. I was thinking about a name for the Architecture, not for the
servlet itself. And actually, the core is not a servlet but a new base
class for my model 2 action classes. Its name is XMLOperation as I have
called my base action classes Operation and JSPOperation :).
Thanks for your input,
Dan
-------------------------------------------
Daniel Lopez Janariz ([EMAIL PROTECTED])
Web Services
Computer Center
Balearic Islands University
-------------------------------------------
>
> 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
