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
