Hi,
>I suppose you could call the controller servlet using a GET
>request with query
>line parameters, but in practice I always used a form for this.
>Sometimes that
>meant creating a form just to encapsulate a submit button that is
>an image --
>but a form nevertheless.
Yeah..but so far I haven't seen a need to ever put an empty form just to
call the servlet. Plus, with JSP you can map the .do like you mention later
on, and just use <jsp:include page="someservlet.do" /> and call the servlet
directly cant you? Not that any form parameters are passed, but I imagine
you can do that if necessary..why I have no clue.
>As you suggest -- if there's no business logic to be done, I don't see any
>problem with linking directly from one JSP page directly to another. In
>essence, the user is manipulating the View without modifying the Model.
Agreed.
>I'm not actually using reflection. All the action classes
>implement something
>like this:
>
> public interface Action {
>
> public void perform(HttpServlet servlet,
> HttpServletRequest request,
> HttpServletResponse response)
> throws IOException, ServletException;
>
> }
>
>so that I just deal with instances of an Action. The advantages include:
>
>* Not all the logic is in one class, so it scales better and
> never runs into a class size limit my JVM might impose.
>
>* The logic can be written by multiple members of a
> team without fighting over a single source module.
>
>* Adding a new action requires zero software changes
> to the controller servlet itself -- just a new configuration
> parameter.
>
>* The controller servlet itself is generic enough to be used
> for multiple web applications.
Very good points. I like your ideas and it does have some merit. However, is
there any difference really in the way your doing it, and using descendant
servlets, one for each form say, much like you use one action class for each
form?
>I tend to use initialization parameters for the controller
>servlet. It would
>be just as simple to load from a properties resource file in the
>init() method.
I think I would prefer the property file just because I can edit it easier
than editing init parameters, plus I would think it might be more portable
to a J2EE app server. From what I have seen, init parameters have to be
defined for each server you use. I could be wrong..but I thought I saw that
somewhere. I know in Orion there is a .xml config file that you define init
parameters for.
>My favorite way is actually the third alternative that I presented in the
>previous response. I map the controller servlet to a filename
>extension like
>"*.do" -- which implies "go do something". Then, my form submit looks
>something like this:
>
<snip>
>The three approaches (hidden parameter, path information, and extension
>mapping) are all functionally equivalent, and roughly the same
>amount of code
>in the controller servlet (one or two lines) -- I just find this
>one makes my
>JSP pages more readable.
I agree with you. It does make for easier reading. The only downside is that
you do have to do some changes on the server. The main one being mapping all
.do files to a specific servlet. But, I have to admit..I like it. Seems the
overall setup is using simple classes to handle the work, instead of
servlets, with only a single servlet to call the action classes. The thing
of it is..if it gets the "class" name from the property file (or init
param), how does it call the class? I would think it has to use reflection
to do that doesn't it? How else do you pass in a String and call a class by
that name?
>In my EJB-based apps, the work is indeed done in the EJB -- the
>action class is
>just an "adapter" that maps from HTTP request parameters into appropriate
>property setting and method calls. In my non-EJB based apps, I
>use business
>logic beans to do all the real work -- and these beans have no
>clue they are
>being invoked in a servlet based environment (i.e. no imports of
>"javax.servlet.*"), so they can be reused in non-servlet-based
>apps as well.
Hmm..interesting. I guess that is what we use really. We use simple classes,
some of them derived from others to include generic functionality. We dont
serialize them, at least not in the sense of a JavaBean that is serialized.
We have "core" classes that contain a session package which is where we put
our session classes. This isn't my design, incidentally..its what was here
when I started. But it does work.
Look forward to your reply. Take care.
===========================================================================
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
