AndySoft wrote:
> > Instead, I prefer to segregate all my business logic (but zero
> > HTML generation)
> > into servlets, which can use EJBs when appropriate or other
> > techniques (such as
> > direct JDBC access) when EJBs are not necessary. I use beans to
> > communicate the
> > processing results back to an appropriate JSP page for display, using
> > RequestDispatcher.forward() to transfer control.
>
> hmm, why don't you use beans in the jsps which have a processRequest(httpreq
> req) method, that gets called automatically with the request object, you can
> do whatever you want in it, access EJB or whatever you want, then you store
> the stuff you want to display into variables with getter method and your jsp
> will display them, there is no java code in the jsp and you don't have to
> create html in your servlet or bean or whatever. and you don't have to
> bother with requestdispacther and such
>
Beans are very useful for lots of things, but managing flow of control is not
one of them. The requirement to direct the flow of control, based on user
input, is very common.
Consider the scenario I described earlier (enter filter criteria on a customer
search screen). Add an additional application requirement -- if the user
specified no criteria at all (and would thus select the entire customer
database), or they specified inconsistent data (such as backwards dates on a
date range), the user should be returned to the input form and see an
informative error message plus the values they have already entered, if any, so
that they can correct and resubmit. If all the criteria look OK, the
application should do the search and display the first page of the results.
In a JSP+bean scenario, the selection criteria are submitted (as you suggest) to
a particular JSP page. But what should be the output of that page, since there
are two valid responses to be supported? How are you going to do the redirect
from within your processRequest() method, since a bean cannot do this? This
issue becomes much more important in a complex workflow based application that
David was asking about, where the number of branches (and even the directions
that they go) are dynamically defined.
You can of course do this in your JSP page by having the processRequest() method
return something like the URL of the next page to be displayed, and then use a
<jsp:forward> (or RequestDispatcher.forward in a scriptlet) to forward to the
correct "next" page. But then you've just eliminated the reason for this "page"
to be JSP instead of servlet, because it's doing control things instead of view
things (using MVC terminology).
Servlets are great for logic (model manipulations as well as flow-of-control
management), and can be coerced into creating presentation (although writing
out.println() statements with embedded HTML is really tiresome). JSPs are great
for presentation, and can be coerced into performing logic (scriptlets). Using
both for what they are best at will result in applications that are more
resilient in the face of the changes that are guaranteed to happen in the
future.
>
> just my 2 cents
> AndySoft
Craig McClanahan
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
