Hi Mike,
I already read Daniels reply to you. Daniel (and Craig) have been a big help
to me in understanding Model 2 a great deal more than I did.
As I have gathered from what they are doing (correct me if I am wrong
fellas), its very similar to what you are talking about. As Daniel said,
there are a few steps you can take. As I am finding out, there are actually
many. My first stab at JSP for the front end has been using Model 1. I am
now realizing how ugly it actually is to manage a Model 1 approach with alot
of pages, especially when sending the forms back to the JSP page and calling
a bean in the JSP page to do the work, redirecting, etc. There is too much
control logic in the JSP page, and Im afraid a normal web developer would be
blown away at trying to understand all this (or..maybe not..just my
intuition).
Here is what I am planning on doing and its using alot of what Craig and
Daniel have told me.
At first, I was using the hidden form field. The problem is, well there are
a few, but the most prominent one I am experiencing is that if you dont keep
track of all the command values, whats being passed in to the servlet, etc
somewhere, and document it, and you or someone else makes a change somewhere
in the servlet structure, you can easily break a number of pages, and cause
alot of problems trying to find out what the heck went wrong.
The other approach is using the servlet path info, such as
action="/servlet/myservlet/action_class" and the /servlet/myservlet would be
called and the path info would be action_class, which you would then call.
The method Craig and Daniel use, which I like best too, is to map a specific
extension to your controller servlet. Thus, as Craig does, *.do maps to say
mypackage.ControllerServlet. This is done at the server level, but once its
done, ALL *.do extension requests go to the servlet. Your action tag looks
like: action="Login.do" instead of something like
action="/servlet/mypackage.LoginServlet/Login". The .do is Craigs preference
because it indicates your doing something..and I agree. Its easy for a web
developer to look at a page with a Login.do and know that its going to login
in.
Part of all this stems, at least for me, from the fact that we want to grow
our development team in a few areas. I currently am doing the front-end
jsp/html pages and most of the JavaBeans they use, in a Model 1 fashion. The
problem is, as I said above, Model 1 is UGLY for a web developer to use, and
I frankly dont want to do web pages anymore. I want to learn my Java skills
beyond what they are now. To do that, I need to structure the front-end so
that a Java developer can do the servlets, action classes, javabeans, etc,
and a web developer can do the JSP pages with minimal effort in using
scriplet code. It also separates the logic from the view completely using
the Model 2 approach, which gives a better MVC than using Model 1 JSP pages.
(sorry if you already know this..Im just rambling on my view of all this).
Needless to say, what I am doing is a single controller servlet, that chops
off the .do of the action name passed in (Craig or Daniel..what is the call
to actually get the MyAction.do string from the request?)
You can even us straight HTML pages instead of JSP for the first form..but I
would ask why? So, we have our sourcePage, it has a form and the action is
Enroll.do (lets assume its an enrollment page). The user fills it out,
clicks submit. It goes to my ControllerServlet which first strips off the
.do and is left with Enroll. I am not quite clear at this point how
Craig/Daniel do the Hashtable lookup thingy, but I assume they have a
hashtable of "action" names and the class that is mapped to each action name
(from the form). If not..then maybe they can elaborate on how they do it at
this stage. None the less, you look up the action name, get the class name,
and do a Class.forName() on it. This class is an ACTION class. It implements
a simple interface called Action (or whatever you want to name it). This
class has one method in it, named perform(HttpServletRequest,
HttpServletResponse). The ControllerSerlvet loads the class (if its not
already loaded) dynamically, and calls the perform() method. That class is
the "logic" on the front-end. That class can connect to EJB if need be,
whatever may be needed. Its that class' job to handle the full logic, or
pass the logic on to the EJB (if using EJB). From there, that class would
create a bean (or beans), populate the bean(s) property(ies) with whatever
the logic has produced and should be displayed, and then the class puts the
bean(s) into the HttpSession (or request) object. The last step is to
forward to the JSP page that will use the bean(s) and display the dynamic
values. The controller servlet would put all this inside a try..catch block.
If an exception occurs, the action class propogates it up to the servlet,
which then sets it in the request object with
setAttribute(javax....EXCEPTION, exception) (sorry..forget the exact call to
make). The JSP page can then display the error, or you can specify a
forwarding error page if need be.
The above is at lest what I will be trying to achieve very soon. If it
works, which from what Craig and Daniel have told me, it will, it should
provide a more functional environment to separate web page design, front-end
server-side logic, middle-tier EJB logic (if used), and back-end database
model.
So..while I probably didn't answer much, I am at least hoping what I have
said gives you a better perspective on what should be done. It is my
preference to do it this way, and there are plenty of other ways to do it I
am sure.
If you have any questions, feel free to ask. If I cant answer them, Daniel
and Craig can I am sure.
Thanks.
===========================================================================
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
