Steve,
I can see your dilemma regarding introducing JavaBean development into your
organization. Using beans might seem to add an unnecessary level of
complexity and an additional learning curve. I can tell you that writing
beans is easy and doesn't require a full IDE, although there are several
very good IDE's that can be downloaded for free and can help make Java
development easier. (ie.JBuilder 5 from Borland www.borland.com) As your
team builds more and more complex pages, you will quickly realize the value
of using Beans, custom tags, and frameworks like Struts and Velocity. Many
people start out with JSP pages that have lots of scriptlets and code in
them. Over time, they realize that having so much code in the pages ends
up costing more in the long run as they require more maintenance and can be
more prone to having bugs and are generally less readable. Don't be
intimidated with the task of writing beans. In the simplest form, they are
simply classes that contain private member variables and corresponding get
and set methods to access them. There is a strict naming convention that
you must adhere to. Variable names always begin with lower case. Typically
you will capitalize the first letter of every word in the variable name
thereafter (ie. temperatureReading, zipCode) You will then provide public
methods to access the variables by prepending get or set to the variable
name and capitalize the first letter (ie. getTemperatureReading,
getZipCode, setZipCode). I'd suggest picking up a book or two such as
Han's JavaServer Pages, Professional Java Server Programming J2EE Edition,
Java Servlet Programming by Jason Hunter. A more high level book that I
like is Core J2EE Patterns, but this might be overkill for you needs.
-Richard
At 01:17 PM 9/7/01 -0700, you wrote:
>Thanks for responses from Richard and Hans! Based on your comments and
>comments from others, using beans is beginning to appear to almost always
>being the best solution. And yet, as Richard said, "It depends." In my
>post, I did not have emphasize that it seems that using request parameters
>may be easier specifically for non-Java savvy developers. Bean creation
>(coding and compiling) is a step above simply using Java as a scripting
>language within JSP. For someone who doesn't know Java, doesn't have a
>development environment for compiling their own beans, and is just creating
>simple pages (one at a time or up to 10 pages within a simple application),
>is it worth the effort to learn about JavaBeans specs and how to compile a
>bean? Or, would it be better to teach them an easier, yet acceptable (i.e.,
>"good enough", but not the best) solution that doesn't require the novice
>JSP coder to take a step up to compiling beans? [Note this is presuming
>that the developer doesn't know Java and is being introduced slowly to it.]
>I'm not personally arguing against teaching how to create beans (in fact,
>this is what I've been arguing, even to someone new to Java), but I am
>receiving push back from others at work that it might make more sense to
>teach a "good enough" approach to novices who are building simple web apps.
>Thus they argue, using request parameters and having to deal with Java as a
>scripting language is OK since it does the job, and the difference in end
>result (seen by the end user) is probably imperceptible. Essentially,
>giving novices baby steps towards the best approach. That is, they can
>learn about and use beans after they learned to walk. So, for this audience
>would the answer change?
>
>Steve
>
> > -----Original Message-----
> > From: Hans Bergsten [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, September 07, 2001 2:29 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Form processing, request parameters, and beans
> >
> >
> > Steve Bang wrote:
> > >
> > > If a user interacts with various HTML form elements (such
> > as checkboxes,
> > > selection lists, and radio buttons) on a page displaying a
> > result set based
> > > on the selected options, what design decisions should I
> > consider in how to
> > > maintain the state of the selections between page reloads?
> > There seem to be
> > > many options, including:
> > >
> > > (1) Using request.getParameter method
> > > (2) Using a simple bean
> > > (3) Using JavaScript to construct the URL
> > > (4) Using hidden form elements
> > >
> > > And, apparently, if Unicode is involved, I'm hearing I
> > might want to use a
> > > POST method rather than a GET, in order to preserve the
> > Unicode characters
> > > properly. It seems that the simplest would be to use the
> > > request.getParameter method. So, when would I use beans instead?
> > >
> > > I'm just learning JSP and how to handle these issues, and
> > am quite puzzled
> > > by what I'm reading (see comments below). There really
> > doesn't seem to be a
> > > consensus, and when solutions are offered, either
> > alternatives are not
> > > readily mentioned or they don't say when one technique is
> > preferred over
> > > another. So, can any of you authors or experts offer sage
> > advice for design
> > > considerations? Am I missing something? It seems that
> > some solutions are
> > > harder than necessary.
> > >
> > > Thanks,
> > > Steve
> > >
> > > =========
> > > Here's some of what I've read:
> > >
> > > Advanced JavaServer Pages (in Chapter 3, HTML Forms) --
> > David M. Geary:
> > > "Using beans to capture state is the preferred method for
> > handling forms..."
> > >
> > > Java Servlet Programming (in Chapter 18, JavaServer
> > Pages)-- Jason Hunter:
> > > - has an example of using a bean to store and retrieve
> > properties from a JSP
> > > page.
> > >
> > > Professional Java Server Programming (chapter 14, Writing
> > Maintainable JSP
> > > Pages) -- chapter author unknown:
> > > "State within a JSP should be held within beans."
> > >
> > > Beans and Form Processing (http://www.jsptut.com/Forms.jsp):
> > > "The standard way of handling forms in JSP is to define a
> > "bean". This is
> > > not a full Java bean. You just need to define a class that
> > has a field
> > > corresponding to each field in a form..."
> > >
> > > JavaServer Pages -- Hans Bersten:
> > > -- excellent book, but maybe I missed this discussion and
> > the book isn't
> > > handy.
> >
> > I'm covering this in my book as well (see Chapter 5, for
> > instance), and
> > recommend using a bean for most situations.
> >
> > A bean makes a lot of sense:
> > 1) If you need to validate the form input, the bean can contain an
> > isValid() method. Using the setProperty action you can easily
> > capture all form input as bean property values. The isValid()
> > method can then be called in a scriptlet with an if statement to
> > decide what to do next. This way, most of the validation code is
> > encapsulated in the bean.
> > 2) If you want
>
> to do something with the form input, such as storing
> > it in a database or use it as data in a mail, using a bean
> > simplifies the interface between the components. You can use
> > setProperty to capture the data and use a custom action that
> > takes the bean as input to do the real work. If you need to add
> > fields to the form later, you just add the corresponding properties
> > to the bean and modify the custom action to handle the new data.
> > 3) Even if all you want to do is to use the form input to set
> > default values the next time the form is displayed, a bean is
> > an advantage over plain request parameters. The reason is that
> > you can use getProperty actions to fill out the form with the
> > current values instead of JSP expressions. The property getter
> > methods in the bean can deal with the null case, while an
> > expression needs to look something like this to handle null:
> >
> > <%= request.getParameter("foo") == null ?
> > "" : request.getParameter("foo") %>
> >
> > I can only think of one case where a bean may be overkill: if you
> > use a custom tag library that also supports some kind of "expression
> > language" that let you access individual request parameter values
> > without using Java code. For instance, with our commercial tag library
> > (InstantOnline Basic), you can display the form with values from
> > request parameters like this:
> >
> > <iob:form action="foo.jsp" method="post">
> > <input name="bar" value="$http|bar$">
> > ...
> > <input type="submit">
> > </iob:form>
> >
> > The $http|bar$ expression is evaluated to the value of the request
> > parameter with the same name. For more about InstantOnline Basic
> > see:
> >
> > <http://www.gefionsoftware.com/InstantOnline/Basic/>
> >
> > Other tag libraries support similar expression languages, such as
> > Jakarta Struts:
> >
> > <http://jakarta.apache.org/struts/>
> >
> > Hans
> > --
> > Hans Bergsten [EMAIL PROTECTED]
> > Gefion Software http://www.gefionsoftware.com
> > Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
> >
> > ==============================================================
> > =============
> > To unsubscribe: mailto [EMAIL PROTECTED] with body:
> > "signoff JSP-INTEREST".
> > For digest: mailto
> >
> > [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
> > 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
> >
> >
>
>===========================================================================
>To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
>JSP-INTEREST".
>For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
>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
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
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
