Model-View-Controller archecture for JSPs

[Talin <ta...@brodia.com>]

This is a suggestion.

We've been using a "Model-View-Controller" paradigm with our JSP pages, and
it's one of the best decisions we ever made.

Some background: Model-View-Controller (MVC) was first introduced with the
SmallTalk user interface on the Alto. The idea is that a GUI can be broken
down into three types of components: The Model which stores the state, the
View which controls the presentation of the state, and the Controller which
allows the editing of the state.

However, in most modern GUIs the View and Controller elements are combined
into a single object, often called a "widget". For example, a slider class
will be both a view (showing the value) and a controller (allowing dragging
of the knob). For GUIs, this combination is generally OK, since there is a
generally a 1:1 correspondance between controllers and views.

A similar situation exists with most web-based applications - the code to
handle input is often intermixed with the code to generate the view, in this
case the HTML output. This is particularly true in the case of JSP pages.
But it is not so clear that combining the view and controller are as good of
an idea here. The JSP examples on the Sun website are a good example of why
combining the view and the controller is in fact NOT a good idea - the code
is strange and hard to understand. Adding a web form into a page also
requires that you embed the logic for handling that form onto the target
page. If several different forms can post to the same page, or the same form
can post to various different pages then you end up having to embed the
logic for handling the query parameters in many different places, and it
quickly becomes confusing. An example of this is a preferences component in
a sidebar which appears on several different pages. The preferences
component has an "update preferences" button which sends a POST to whichever
page is currently being viewed. The same page is redisplayed with the new
preferences. Seperating the view from the controller allows the logic for
changing preferences to be centralized in a single location.

I've been looking around the web, and I've noticed a couple of attempts to
seperate the handling of input from the generation of pages, but in many
cases this seperation is done in a way that is either incomplete, hard to
use, or doesn't work with JSP pages. Of course, I haven't seen everything
that's out there...

Anyway, the system that I have is very simple: There is a RequestHandler
class which is used to handle the incoming HTTP request. This is similar but
not identical to the Tomcat concept of interceptors. To create a new
handler, you need to subclass the RequestHandler class and then register
that class with the handler manager. (The registration is handled by listing
each handler in the configuration file). Each handler has a unique ID
string, which is used as a hash table key to get access to that handler.

Handlers are invoked using the query parameter "handler=". In our servlet,
if we see a "handler" parameter, we grab the value of that param and look it
up in the hash table, which results in the handler object. The handler is
then passed the request and response objects (and some other context info).
Handlers can do redirects and forwards if needed. (Note: Originally I was
just going to have the handler parameter be just the name of the class, but
this turns out to be a bad security hole.)

Note that unlike interceptors, only one handler can be run per request.
However, that's generally OK, since the user can only hit one submit button
at a time. Also unlike interceptors, the handler that gets run is different
for different forms. (You could easily implement the handler system using
interceptors, however.)

Calling a handler from a FORM is simple: For example, in the preferences
panel, all you would have to do is say:

	<form method="POST" action="<%= getThisURI() %>?handler=prefs"> ...
etc.

This means that the preferences component can easily be included in any
page. Just add one line of JSP code to include the component and you're
done.

What we've learned is that the handler system is easy to use and contributes
to an overall cleanliness and organization of JSP pages - in fact, we pretty
much use handlers for all processing of input, even if it's a case that's so
simple that the handler system isn't needed.

One thing that the system lacks is the ability to add handlers while the
server is running, the same way that JSP pages can be edited and added.
However, this hasn't been a big problem for us.

Anyway, I'm sure many of you have thought about this already, although not
in perhaps the same terms. I mean, it seems so simple and obvious...at the
same time, I've seen a lot of code examples out there which suffer badly
because they haven't adopted a model like this.

Re: XML support in Tomcat 3.1

[Mark Brouwer <ma...@virgil.nl>]

Danno Ferrin wrote:
> 
> The real problem is that the XML tags as supported in JWSDK is a
> mis-implemntation of the spec.  Mixing the classic and XML tags was
> never intended to be allowed, and Eduardo cleared that up in this list a
> little over a month ago.  The fact that it broke some backward
> compatibility was discussed, but the nature of Jakarta as a reference
> implementation requires strict adherence to what the spec actually says,
> not to what was implemented that was a mis-interpretation of the spec.
> 

OKE, I did see a thread at the moment but didn't pay that much attention
to it. I did look for an archive but was not successful.

>
> Just using <jsp:expression> ... </jsp:expression> as a replacement for
> <%@ ... %> is not proper according to the 1.0 or 1.1 spec without the
> presence of a jsp:root element and following the XML conventions in the
>

That's correct, however to be 'future proof' we inserted the root tag
and the document type declaration already (based on the JSP 1.1 specs,
we did know this was not final). We had them out commented for the ended
up in the HTML documents we generate, but support was there :-)

>
> content.  Furthermore the section of the spec that talks about XML pages
> discusses a transformation into an XML document from a JSP page, and
> implies thusly that the use of the XML tags should only be used in a
> fully transformed document.  The RI does not yet serve JSP pages that
> are stored as XML documents, but this is not to critical since the spec
> says that the transformation is not visible to JSP pages.  Furthermore
> there is no indication that the JSP tags are going to go away, so using
> the XML document transformation is not needed to "future proof" JSP
> pages.
> 

I know, but as we try do do as many as possible in XML notation (where
applicable) we thought a long time ago to make the right move.

> Perhaps what is needed is a tool that will de-XMLize jsp pages with
> mixed XMl and JSP tags into a JSP page.  Would this solve your problem?
> 

Well, to be honest I'm not that found of tools playing around with my
code, for matters of coding conventions etc. Just a matter of giving our
developers a lot of beer to do the job.

Thanks for the info,
-- 
Mark Brouwer
Virgil B.V.

Re: XML support in Tomcat 3.1

[Danno Ferrin <sh...@earthlink.net>]

The real problem is that the XML tags as supported in JWSDK is a
mis-implemntation of the spec.  Mixing the classic and XML tags was
never intended to be allowed, and Eduardo cleared that up in this list a
little over a month ago.  The fact that it broke some backward
compatibility was discussed, but the nature of Jakarta as a reference
implementation requires strict adherence to what the spec actually says,
not to what was implemented that was a mis-interpretation of the spec.

Just using <jsp:expression> ... </jsp:expression> as a replacement for
<%@ ... %> is not proper according to the 1.0 or 1.1 spec without the
presence of a jsp:root element and following the XML conventions in the
content.  Furthermore the section of the spec that talks about XML pages
discusses a transformation into an XML document from a JSP page, and
implies thusly that the use of the XML tags should only be used in a
fully transformed document.  The RI does not yet serve JSP pages that
are stored as XML documents, but this is not to critical since the spec
says that the transformation is not visible to JSP pages.  Furthermore
there is no indication that the JSP tags are going to go away, so using
the XML document transformation is not needed to "future proof" JSP
pages.

Perhaps what is needed is a tool that will de-XMLize jsp pages with
mixed XMl and JSP tags into a JSP page.  Would this solve your problem?

--Danno

Mark Brouwer wrote:
> 
> Today I thought about migrating our JSP 1.0 applications to Tomcat 3.1
> milestone 1, but the result was not that satisfactory. It seems support
> for the XML equivalent of JSP tags has been removed in Tomcat 3.1,
> leaving us with pretty :-( looking generated pages.
> 
> I know the promised part of 'JSP pages as XML documents' didn't make the
> JSP 1.1 specs, but withdrawing simple support as provided in JSWDK seems
> a little bit drastic to me.
> 
> We thought to be future proof by using all the XML equivalents and are
> left with 3 options now: using another JSP 1.1 engine, wait for the next
> JSP specs or change everything back so I can change it again in the
> future. None of these options make me smile, please put the support back
> in.
> --
> Mark Brouwer
> Virgil B.V.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

RE: XML support in Tomcat 3.1

[Kevin Jones <ke...@develop.com>]

Doea anybody have a copy of Eduardo's post - I've searched the archives and
can't find it,

thanks,

Kevin Jones
DevelopMentor

> -----Original Message-----
> From: Mark Brouwer [mailto:mark.brouwer@virgil.nl]
> Sent: 25 February 2000 16:19
> To: tomcat-dev@jakarta.apache.org
> Subject: XML support in Tomcat 3.1
>
>
> Today I thought about migrating our JSP 1.0 applications to Tomcat 3.1
> milestone 1, but the result was not that satisfactory. It seems support
> for the XML equivalent of JSP tags has been removed in Tomcat 3.1,
> leaving us with pretty :-( looking generated pages.
>
> I know the promised part of 'JSP pages as XML documents' didn't make the
> JSP 1.1 specs, but withdrawing simple support as provided in JSWDK seems
> a little bit drastic to me.
>
> We thought to be future proof by using all the XML equivalents and are
> left with 3 options now: using another JSP 1.1 engine, wait for the next
> JSP specs or change everything back so I can change it again in the
> future. None of these options make me smile, please put the support back
> in.
> --
> Mark Brouwer
> Virgil B.V.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

XML support in Tomcat 3.1

[Mark Brouwer <ma...@virgil.nl>]

Today I thought about migrating our JSP 1.0 applications to Tomcat 3.1
milestone 1, but the result was not that satisfactory. It seems support
for the XML equivalent of JSP tags has been removed in Tomcat 3.1,
leaving us with pretty :-( looking generated pages.

I know the promised part of 'JSP pages as XML documents' didn't make the
JSP 1.1 specs, but withdrawing simple support as provided in JSWDK seems
a little bit drastic to me.

We thought to be future proof by using all the XML equivalents and are
left with 3 options now: using another JSP 1.1 engine, wait for the next
JSP specs or change everything back so I can change it again in the
future. None of these options make me smile, please put the support back
in.
-- 
Mark Brouwer
Virgil B.V.

Re: Model-View-Controller archecture for JSPs

[Jesper Jørgensen <je...@caput.com>]

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
-- 
Jesper Jorgensen         Caput ApS       Tel +45 33 12 24 42             
jesper@caput.com         Nygade 6        Fax +45 33 91 24 42
http://www.caput.com     DK-1164 Kbh K