Hello Wes,
Yes the approach I was suggesting has the Servlet working with non JSP
Classes to complete the unit of work that the user was requesting and the
JSP handle formatting and display only. For instance an orderEdit Servlet
may work with a shopping cart EJB and account EJB to change a customers
order. When the orderEdit Servlet was complete it may create an order edit
view bean that contains the properties that the order edit JSP needs to
present the updated order back to the customer. The Order Edit JSP is only
responsible for creating dynamic portions of the HTML page and it
collaborates with the order edit view bean.
The November issue of Java Report contains an article titled JSP and
Servlets: A powerful pair by Dan Malks that contains a description of this
approach. He calls it the "Service to Workers" pattern. There is also an
article in December issue of Java Report by Akerley et al. in which they
propose that the JSP is relegated to the role of formatting and display.
regards,
Bill Bomberry
> -----Original Message-----
> From: Williams, Wes [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, January 05, 2000 10:55 AM
> To: Bomberry Bill
> Cc: [EMAIL PROTECTED]
> Subject: RE: Beans vs. Classes
>
> Bill,
>
> I'm sure it's me but I had difficulty visualizing scenario (2). I think
> it's
> saying that the servlet would be contacted first, the servlet does some
> work, the servlet invokes the JSP page for formatting, the JSP page
> returns
> formatted HTML to the servlet, the servlet returns the formatted HTML to
> the
> client. Is that what (2) is saying?
>
> Sincerely,
> Wes Williams
>
> > -----Original Message-----
> > From: Bomberry Bill [SMTP:[EMAIL PROTECTED]]
> > Sent: Tuesday, January 04, 2000 9:17 PM
> > Subject: Re: Beans vs. Classes
> >
> > If the JSP page has input fields possible reasons to use the bean
> include
> > the following:
> >
> > 2) If you decide to use the Servlet as the View Controller and relegate
> > the
> > JSP to formatting and display, you would not invoke the JSP page until
> the
> > unit of work the Servlet was processing was complete. But a bean would
> > still
> > have benefit as you could write a simple method that used reflection
> and
> > the bean interface to map the Servlet request parameters to the bean.
> This
> > mapping assumes that the ServletRequest parameter names match the
> > associated bean property names. In this vein you might have one Bean per
> > JSP
> > page.
> >
> > Beans used in this way encapsulate the data of the ServletRequest
> object.
> >
> > regards,
> > Bill Bomberry
> >
> > > -----Original Message-----
> > > From: Patrick Regan [SMTP:[EMAIL PROTECTED]]
> > > Sent: Tuesday, January 04, 2000 1:09 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Beans vs. Classes
> > >
> > > I am trying to determine what the benefits are to using beans over
> just
> > > an ordinary class. From the little that I know, I don't see the
> > > benefit.
> > >
> > > Take the calendar example for a bean (here is the JSP code) :
> > >
> > > <html>
> > > <jsp:useBean id="clock" class="calendar.jspCalendar"/>
> > > <ul>
> > > <li>Day:<%= clock.getDayOfMonth() %>
> > > <li>Year:<%= clock.getYear() %>
> > > </ul>
> > > </html>
> > >
> > > Versus just an ordinary server-side java class (here is the JSP code):
> > >
> > > <html>
> > > <% JspCalendar clock = new JspCalendar() %>
> > > <ul>
> > > <li>Day:<%= clock.getDayOfMonth() %>
> > > <li>Year:<%= clock.getYear() %>
> > > </ul>
> > > </html>
> > >
> > > Can someone give me an idea of why I should use beans over a regular
> > > server-side class?
> > >
> >
===========================================================================
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
