Kevin Duffey wrote:
> Hi Craig,
>
> Thanks for the reply. I will do the same as you..put my comments in below
> yours.
>
> >Sounds like you are going the right direction for the right reasons.
>
> Most definitely.
>
> >In my apps, I chose to link directly to the next JSP page when there was
> >no business logic that needed to be executed -- for example, navigation
> >links and the like. Otherwise, I always filter through the controller
> >servlet.
>
> Sounds exactly like what I was aiming for. Just want to make sure you mean
> that when you filter through the controller servlet, its always a
> form..right? Form data I believe would be the only reason to go through the
> servlet, otherwise its a link to another page that doesn't require any
> business logic.
>
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.
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.
>
> >The approach I use is to divide the business logic parts into separate
> >classes that implement an Action interface, rather than being methods in a
> >paticular servlet. The name of the class to use for each selection is
> >stored in a Hashtable (loaded in the init() method). Fundamentally, my
> >controller's doGet() servlet looks like this:
> >
> >* Extract the selection code as described above.
> >
> >* Use that to do a hashtable lookup, and retrieve
> > the class name of the action class to use.
> >
> >* Use the class name to look up an action class
> > instance of this class in a second hashtable (the
> > first time a particular action class is used, I
> > create a new instance and store it here, under the
> > class name).
> >
> >* Call the perform() method of this action class
> > (the method is defined in the Action inteface).
> >
> >This avoids having all the logic in a single class, and having to use a
> >big switch or if/else chain to call the right method.
>
> Sounds good..but a bit more work than I think is necessary for this. I take
> it your using reflection for this? Its an interesting approach.
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.
> Do you use a
> property file to store the class names for actions?
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.
> How is your Controller
> servlet actually implemented to get the "action" from a form? Are you using
> the hidden command field with the name of the class to call or something? I
> honestly thinnk a hidden field is easier to work with than extra path info.
> Probably nothing much different.
>
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:
<form method="POST" action="saveCustomer.do">
...
</form>
in one page, and something like this:
<form method="POST" action="listOrders.do">
...
</form>
in a different page. The controller servlet itself receives either of these
submits, and then uses getServletPath() to determine how it was called (which
results in either "/saveCustomer.do" or "/listOrders.do"). I strip off the
extension (so that the servlet doesn't care which one you really mapped it to),
and then use the resulting string ("/saveCustomer" or "/listOrders") to pick
the right action class.
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.
> >That's what I do, although not all my apps need EJBs. Basically, the
> >action method in the controller servlet uses session attributes, or
> >request attributes (depending on how long I need the data) to pass results
> >on to "view" JSP pages.
>
> But, the "work" is done in the EJB, right? Or do you actually do logic in
> you Action class that is called by the Controller servlet? If you do, does
> that mean your Action classes can become EJB when you move to it? I would
> think your action class(es) would not do the logic..it would merely connect
> to an EJB to do the logic.
>
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.
>
> >Yep squared.
> >
> >You might also look at using JSP "custom tags" to create complex HTML
> >representations of your business objects.
>
> Well, we are using JSP 1.0, not 1.1, so I cant use custom tags at this
> point.
So you've got something to look forward to in the future :-).
Craig
===========================================================================
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
