KDF (Kevin Duffey's Framework)
KDF is now THESEUS

Kevin on Model 1, Model 1.5 and Model 2
From: "Duffey, Kevin"
To: JSP-INTEREST@JAVA.SUN.COM
Subject: Re: setItem vs request/session (redirected)
Date: Monday, November 20, 2000 8:35 PM

Ahh the Model 1, Model 1.5 and Model 2 debate. I know it well. I used to be
a Model 1.5 developer. Here are some of the differences:

Model 1:
  All code is in the JSP page. You use JSP pages with code and submit to JSP
pages with code. You do logic, etc in your JSP page.

Model 1.5:
  Most code is in a javabean that your JSP page uses. When you submit a
form, you submit it "back" to the JSP page, which has a scriplet that then
determines if its a form submission..or the first time its being executed.
If its not the first time..it must be a form being submitted..so it calls a
javabean method passing in request, response, session, etc so that the
javabean method does the logic.

Model 2:
  All JSP pages have very little scriplet code. They use path mapping or
extension mapping to direct all submissions to a single controller servlet.
That single point of entry can then direct to any number of classes
depending on the "command" being passed in. This often follows a true MVC
model, and usually requires a command pattern to be used properly (which
allows the controller servlet to determine what class to call to handle the
request).


Strengths/Weaknesses:

Model 1:
  Strength:  Very easy to implement, initially requires "no brainer"
knowledge of JSP and Java.
  Weakness:  Very quickly becomes a mess. It is quite like using Servlets to
return your HTML, but in the opposite end of the spectrum. Instead of code
with HTML in it, you now have HTML with code in it. It is ugly to work with
and difficult to maintain..especially because most people don't comment
their code, even more so in JSP pages.

Model 1.5:
  Strength:  Much like Model 1..very easy to implement, so its fast to
prototype pages and functionality. Better than Model 1 because it now
removes alot of "logic" code out of JSP pages and puts it into JavaBeans.
  Weakness:  Still uses a bit of java code in JSP and requires forms/links
to be submitted to itself for processing (or to another JSP page that then
calls the bean..which results in more coding). Much like Model 1, it can get
ugly as you add more JSP scriplet code. It doesn't cleanly separate the VIEW
from the CONTROLLER in the MVC approach.

Model 2:
  Strength:  Cleanly separates Java controlling code from jsp pages (and
javabeans). It allows a javabean to be the "model" of the users state (think
of wizards..multiple pages to build up a single transaction..using a
javabean you can store the state of that user as he/she progresses through
the pages. You can do this with the other models too..but this cleanly leave
the javabean to just storing the state..no logic code that jsp pages call).
It also does something the others don't do (they can..but its more work..and
it involves putting "logic" in the jsp page). It allows a single point of
entry for all requests (as long as they all use the mapping that calls the
controller servlet). Because of this, you can put security measures in your
controller servlet, such as making sure if a user tries to access a specific
page (via the url they are going to), they have proper permission to do so.
More so, this approach allows very easy scalability that the other two
approaches don't do very well. Even better..for a developer it is much
easier to maintain coming in to a project.
  Weakness:  More difficult to implement (from scratch), more work to add
functionality. Requires more "knowledge" of servlets, jsps, javabeans and
the MVC paradigm.

So let me divulge a bit on why Model 2 is the MVC of choice! First..and
foremost, it "usually" requires more work. I say usually because if you were
to do it from scratch, you would have to write the controller servlet, the
framework for calling the right classes, etc. However, it just so happens
that this stuff has been around for a while, so there are alot of already
pre-built frameworks you can use. If you go to jakarta.apache.org, and go to
the Struts link, Struts is one. Its an OpenSource project that incorporates
a whole hell of a lot! The only down side to using Struts..is if you want to
keep "current" with it, you can't modify the source yourself..the later
versions will undo what you did..so you would have to apply them every time.
On the other hand..I decided to write one myself, that is very short, only 5
classes, and you can modify the source all you want. Ideally, you want to
modify the Controller Servlet to include your security measures. I didn't
write mine in such a way that it calls any "hooks" that you can override,
but because I offer my code free, you can modify it all you want. My
framework is much like Struts, only that Struts provides a nice ability to
load a single action.xml file that contains all the action names and
mappings, where as my mappings are contained in the ControllerServlet in
code.

At any rate..I gotta get back to work..so grab Struts, look at the
documentation..it has very good docs on how to use it. If you like it..use
it..its free. It does require a Servlet 2.2 engine however, which is a J2EE
move. If your using an older Servlet 2.1 engine, my framework will work
fine. My framework is a bit faster than Struts, but Struts offers
international abilities, the single xml config file, etc. Another nice
feature of Struts is auto-bean population. You specify a javabean that a JSP
page will use, and upon submitting the form, it auto-populates the bean with
form element names from the form submitted if they match the methods..just
like using the <jsp:setProperty property="*" /> call on JSP pages. Only, the
downside to Struts is that EVERY SINGLE SUBMISSION tries to auto-populate a
bean. My framework gets rid of that problem and only populates a bean if you
supply a auto-populate=true request parameter. I also use a simple
reflection technique to call a method directly in an action class, whereas
Struts requires you to have a bit longer perform() method that returns a
mapping object and so on.

So read up on the docs of Struts, tell me if you like my framework..and let
me know what you think. Lastly..I will say this..even though Model 1 and
Model 1.5 are "fast" to prototype, with my framework (and Struts) its much
faster! Because all the work is done in setting up the mapping, the
"default" logic, etc..you simply add a JSP page with HTML in it (and you use
a javabean to "get" the form state info for the form elements), create an
action class and add a mapping. I can create a new area of functionality
with my framework in a matter of minutes. The page may not do anything
initially..but it is very fast. You create a JSP page (or more), a JavaBean
that will hold the state, a mapping in the ControllerServlet, and an action
class with one method per "action" you want your page(s) to take based on
the user buttons clicked.

Hope that helps.

the following is a "hit counter" only

Click Here!