tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Talin <>
Subject RE: Model-View-Controller archecture for JSPs
Date Wed, 01 Mar 2000 00:01:33 GMT
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=" 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ørgensen []
Sent: Monday, February 28, 2000 1:07 AM
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 Jorgensen         Caput ApS       Tel +45 33 12 24 42             Nygade 6        Fax +45 33 91 24 42     DK-1164 Kbh K

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message