Hi all,
Thanks a million!!!..
Cheers,
Dheepa
"Craig R. McClanahan" wrote:
> 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
===========================================================================
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
