14-02-2013, 03:23 PM
HANDLING THE CLIENT REQUEST: FORM DATA
1HANDLING THE CLIENT.pdf (Size: 717.82 KB / Downloads: 78)
INTRODUCTION
One of the main motivations for building Web pages dynamically is so that the result
can be based upon user input. This chapter shows you how to access that input (Sections
4.1–4.4). It also shows you how to use default values when some of the expected
parameters are missing (Section 4.5), how to filter < and > out of the request data to
avoid messing up the HTML results (Section 4.6), how to create “form beans” that
can be automatically populated from the request data (Section 4.7), and how, when
required request parameters are missing, to redisplay the form with the missing values
highlighted (Section 4.8).
The Role of Form Data
If you’ve ever used a search engine, visited an online bookstore, tracked stocks on the
Web, or asked a Web-based site for quotes on plane tickets, you’ve probably seen
funny-looking URLs like http://host/path?user=Marty+Hall&origin=bwi&dest=sfo.
The part after the question mark (i.e., user=Marty+Hall&origin=bwi&dest=sfo) is
known as form data (or query data) and is the most common way to get information
from a Web page to a server-side program. Form data can be attached to the end of
the URL after a question mark (as above) for GET requests; form data can also be
sent to the server on a separate line for POST requests.
Reading Form Data from Servlets
One of the nice features of servlets is that all of this form parsing is handled automatically.
You call request.getParameter to get the value of a form parameter. You
can also call request.getParameterValues if the parameter appears more than
once, or you can call request.getParameterNames if you want a complete list of
all parameters in the current request. In the rare cases in which you need to read the
raw request data and parse it yourself, call getReader or getInputStream.
Reading Single Values: getParameter
To read a request (form) parameter, you simply call the getParameter method of
HttpServletRequest, supplying the case-sensitive parameter name as an argument.
You supply the parameter name exactly as it appeared in the HTML source
code, and you get the result exactly as the end user entered it; any necessary
URL-decoding is done automatically. Unlike the case with many alternatives to servlet
technology, you use getParameter exactly the same way when the data is sent
by GET (i.e., from within the doGet method) as you do when it is sent by POST (i.e.,
from within doPost); the servlet knows which request method the client used and
automatically uses the appropriate method to read the data. An empty String is
returned if the parameter exists but has no value (i.e., the user left the corresponding
textfield empty when submitting the form), and null is returned if there was no
such parameter.
Reading Multiple Values: getParameterValues
If the same parameter name might appear in the form data more than once, you
should call getParameterValues (which returns an array of strings) instead of
getParameter (which returns a single string corresponding to the first occurrence
of the parameter). The return value of getParameterValues is null for nonexistent
parameter names and is a one-element array when the parameter has only a single
value.
Now, if you are the author of the HTML form, it is usually best to ensure that
each textfield, checkbox, or other user interface element has a unique name.
That way, you can just stick with the simpler getParameter method and avoid
getParameterValues altogether. However, you sometimes write servlets or JSP
pages that handle other people’s HTML forms, so you have to be able to deal with all
possible cases. Besides, multiselectable list boxes (i.e., HTML SELECT elements
with the MULTIPLE attribute set; see Chapter 19 for details) repeat the parameter
name for each selected element in the list. So, you cannot always avoid multiple
values.
Looking Up Parameter Names:
getParameterNames and getParameterMap
Most servlets look for a specific set of parameter names; in most cases, if the servlet
does not know the name of the parameter, it does not know what to do with it either.
So, your primary tool should be getParameter. However, it is sometimes useful to
get a full list of parameter names. The primary utility of the full list is debugging, but
you occasionally use the list for applications where the parameter names are very
dynamic. For example, the names themselves might tell the system what to do with
the parameters (e.g., row-1-col-3-value), the system might build a database
update assuming that the parameter names are database column names, or the servlet
might look for a few specific names and then pass the rest of the names to another
application.
Example: Reading
Three Parameters
Listing 4.1 presents a simple servlet called ThreeParams that reads form parameters
named param1, param2, and param3 and places their values in a bulleted
list. Although you are required to specify response settings (see Chapters 6 and 7)
before beginning to generate the content, you are not required to read the request
parameters at any particular place in your code. So, we read the parameters only
when we are ready to use them. Also recall that since the ThreeParams class is in
the coreservlets package, it is deployed to the coreservlets subdirectory of the
WEB-INF/classes directory of your Web application (the default Web application in
this case).