Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <21A1A2527491D311A04E009027D4DF5319531F@SFOM01>
From: Talin <talin@brodia.com>
To: "'tomcat-dev@jakarta.apache.org'" <tomcat-dev@jakarta.apache.org>
Subject: RE: Model-View-Controller archecture for JSPs
Date: Tue, 29 Feb 2000 16:01:33 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The points you make are excellent and insightful.

We did in fact manage to implement a MVC model without going outside =
the
Servlet API - sort of. We created "sub-servlets" - that is, each JSP =
page,
instead of being a first-class servlet in it's own right, is actually a
sub-servlet dispatched by the main servlet. The main servlet conforms =
to the
Servlet API, but the sub-servlets have a slightly different calling
convention that allows them to take arbitrary parameters. So instead of
calling "service", you call "apply( Object[] args )" with Java =
parameters.
Of course, we had to re-write large parts of the JSP template compiler =
to do
this. At the time we wrote this, the "jsp:include page=3D" syntax had =
not been
defined yet, so we developed our own syntax. In some ways I like our =
method
better, because the jsp:include style of doing things requires that the
arguments be rendered back into query parameters, and then the whole =
thing
is converted into a request which is inserted back into the servlet =
engine
at the top of the chain; Whereas in our method, it's an ordinary Java
subroutine call to the apply() method of the JSP page. This makes a
component-based model very efficient, and is more intuitive than =
rendering
Java objects into text and then back into Java again.

Another descision we made (and which we do not regret) is that the
"component" JSP files are in their own, independent document root, =
making it
impossible for a user to type a URI that executes a component in =
isolation.
Since we are a highly secure ("bank grade") site, it's important to cut =
down
on the number of ways that a piece of code could potentially be =
executed by
a hostile user.

I've tried writing servlets using the "canonical" JSP methods defined =
in the
current Tomcat implementation, and I find that our current system, =
while not
as theoretically "pure", has a kind of ad-hoc practicality that makes
writing components relatively easy compared to the "official" way of =
doing
things. Of course, this may just be due to my greater familiarity with =
our
own system.

-----Original Message-----
From: Jesper J=F8rgensen [mailto:jesper@caput.com]
Sent: Monday, February 28, 2000 1:07 AM
To: tomcat-dev@jakarta.apache.org
Subject: Re: Model-View-Controller archecture for JSPs


We have come up with roughly the same solution to the same problem. It
has been a problem that has bothered us for more than a year now.

An interesting aspect in building a modular controller design is that
the servlet API really does not support it well. In order to do such a
design you need one single point of entry for all requests regardless =
of
"resource location". By this I mean, that nomatter what the URI is, the
controller should handle it the same way. Since servlets are mapped to =
a
part of the URI, such a controller cannot be implemented in the servlet
API. One exception though: You _could_ put it in a servlet mapped to =
"/"
but this does not always work when you also want to use other
servlets/JSPs in the same servlet engine.

A solution is to use interceptors and the like. But it's a shame to =
have
to go outside the servlet API.

By the way, Sun has wrote about this in their "Developing enterprise
applications" (somewhere on the java site). They suggest implementing
the controller as a "front component" in a servlet or JSP that will
always be called as the first thing in a request. I guess that's the
only solution with the current Sun API's.

What we are looking for in particular is a separation that works well
when we as component vendors sell components for some sort of web
application platform (our own, j2ee, weblogic etc.) and then our
customers gets full control over presentation (the html/jsp stuff) in a
simple and flexible/extensible way.

Jesper
--=20
Jesper Jorgensen         Caput ApS       Tel +45 33 12 24 42            =
=20
jesper@caput.com         Nygade 6        Fax +45 33 91 24 42
http://www.caput.com     DK-1164 Kbh K

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org