June 24, 2018
Hot Topics:

Reading Data from Web Pages: Buttons and Text Fields

  • February 20, 2003
  • By Sams Publishing
  • Send Email »
  • More Articles »

This material is from Chapter 4, Reading Data from Web Pages: Buttons and Text Fields, from the book Sams Teach Yourself JavaServer Pages in 21 Days (ISBN: 0-672-32449-0) written by Steven Holzner, published by Sams Publishing.

Day 4: Reading Data from Web Pages: Buttons and Text Fields

Day 4: Reading Data from Web Pages: Buttons and Text Fields

Today, the gloves come off and we get down to some serious JSP programming—the kind that JSP was built for. In the previous two days, we've been gearing up our Java expertise, and now we'll put it to work as we create JSP programs that let the user send data to us.

We'll do that by seeing how to work with HTML controls today and tomorrow. Controls are those built-in HTML elements that the user can interact with and enter data in, such as buttons, check boxes, text fields (sometimes called text boxes because that's what they're called in various programs, but the true HTML name is text field), drop-down lists, and so on. We're going to put these HTML controls to work starting now. Here's an overview of today's topics:

  • Supporting HTML controls

  • Working with HTML forms

  • Submitting forms to the server

  • Using request objects

  • Using text fields and submit buttons

  • Using text areas, password controls, and hidden controls

  • Using buttons

Today's work will start by seeing how to place HTML controls in HTML Web pages, using HTML forms. As you probably know, HTML forms aren't visible in Web pages; they're purely HTML constructs that enclose HTML controls. We'll need forms to handle HTML controls in our Web pages, because browsers insist that controls be embedded in forms. You'll learn about creating HTML forms and configuring them as you need them.

When the user clicks a submit button in our Web pages, all the data in the various controls (such as text in the text fields) is sent back to the server. In JSP, you can get access to that data using the built-in request object (an object of the Java javax.servlet. http.HttpServletRequest class). You'll see the request object today and what it can do for you as we extract the data the user has sent.

That's what this and the next day are all about—adding HTML controls to Web pages and reading the data the user entered into those controls. Let's start with an overview of exactly what HTML controls are available to us.

HTML Controls

It turns out that there are plenty of HTML controls available. Here's the list, including the HTML element you use to create them—note in particular that many HTML controls are created with the <INPUT> element, using a different value for the TYPE attribute to create the various different controls:

  • Text fields (<INPUT TYPE="TEXT">)—These controls let the user enter and edit a line of text. They're the most common text-oriented HTML controls.

  • Buttons (<INPUT TYPE="BUTTON">)—The standard clickable buttons you see in so many Web pages these days.

  • Check boxes (<INPUT TYPE="CHECKBOX">)—Usually displayed as a small box with a check mark in it. The user can toggle the check mark on or off by clicking the check box.

  • Radio buttons (<INPUT TYPE="RADIO">)—Usually displayed as a circle that, when selected, displays a dot in the middle, these controls act much like check boxes, except that they work in mutually exclusive groups; only one radio button may be selected at a time.

  • File uploading controls (<INPUT TYPE="FILE">)—Allow the user to upload files to the server.

  • Hidden controls (<INPUT TYPE="HIDDEN">)—Hidden controls store data that is not visible to the user (unless she views the page's HTML source).

  • Password controls (<INPUT TYPE="PASSWORD">)—Like a text field, but this control masks each typed character by simply displaying an asterisk (*) instead of the character itself. That means this control is good for typing in passwords, because if someone is peeking over your shoulder, he can't read your password on the screen. (Watching your fingers on the keyboard is, of course, another matter.)

  • Reset buttons (<INPUT TYPE="RESET">)—Reset buttons are great for complex forms, because they let the users clear all the data they've entered to start over.

  • Submit buttons (<INPUT TYPE="SUBMIT">)—The submit button is a very important control in forms, because when you click this button, all the data in the form (that is, all the data in the controls in the form) is sent to a Web server for more processing.

  • Image controls (<INPUT TYPE="IMAGE">)—Just like submit buttons, except they are images the user can click. The actual location that the user clicked in the image is also sent to the server with the rest of the data from the form.

  • Selection lists (<SELECT>)—Also called select controls, these controls work much like drop-down list boxes.

  • Customizable Buttons (<BUTTON>)—This element is a button that can display images and other HTML inside itself.

  • Text areas (<TEXTAREA>)—These controls are two-dimensional text fields, enabling the user to enter more than one line of text. Text areas can also support text wrapping.

The next step is to start adding these controls to Web pages and making use of them in JSP code. To place an HTML control in a Web page, you need to enclose it in an HTML form.

HTML Forms

HTML controls must be enclosed in HTML forms, which you create with the <FORM> element. For example, if you want to add a text field to a Web page using the <INPUT TYPE="TEXT"> element, that element must be inside a form:

    <TITLE>Enter Your Data!</TITLE>

    <H1>Enter Your Data!</H1>
    <FORM NAME="form1" ACTION="jsp1.jsp" METHOD="POST">
      <INPUT TYPE="TEXT" NAME="text">
      <INPUT TYPE="SUBMIT" VALUE="Click Me!">

Tip - The <FORM> element has been around since the first versions of both Internet Explorer and Netscape Navigator. Technically speaking, you don't need a form to display HTML controls for Internet Explorer. However, we'll need forms to indicate where the data in our HTML controls is to be sent. In Netscape Navigator, you need forms—the browser won't display controls unless they're in an HTML form.

The attributes of the <FORM> element are going to be very important to us, because they'll let us indicate where the data in our Web page is to be sent. Here are the attributes of the <FORM> element and what they do:

  • ACCEPT-CHARSET—Indicates a list of possible language character sets for the form data. This attribute is supported by the World Wide Web Consortium (W3C) for the <FORM> element, but is not supported in Internet Explorer or Netscape Navigator yet.

  • ACTION—This attribute gives the URL that will handle the form data. Note that you can omit this attribute, in which case its default is the URL of the current document. Set to an URL.

  • CLASS—The style class of the element. Internet Explorer only.

  • DIR—Gives the direction of directionally-neutral text (text that doesn't have inherent direction, so you should read it). Possible values are LTR (left-to-right text or table), and RTL (right-to-left text or table). Internet Explorer only.

  • ENCTYPE—Sets the MIME (Multipurpose Internet Mail Extension) type used to encode the name/value pairs when sent to the action URL. We won't use this until later in the book, such as in Day 20, "Creating Images on the Server and Handling Internet Programming." The default is "application/x-www-form-urlencoded", but you can also use "multipart/form-data", which creates multipart forms, as for <INPUT TYPE="FILE"> elements.

  • ID—A unique alphanumeric identifier for the form element, which you can use to refer to it. Internet Explorer only.

  • LANG—Base language used for the form element. Internet Explorer only.

  • LANGUAGE—Scripting language used for the form element. Internet Explorer only.

  • METHOD—Specifies the method or protocol for sending data to the target action URL. The GET method is the default. This method sends all form name/value pair information in an URL that looks like URL?name=value&name=value&name=value, as we'll discuss today. On the other hand, using the POST method, the contents of the form are encoded, as with the GET method, but are sent in environment variables. Set to GET (the default) or POST.

  • NAME—Holds a name for the form, so that you can reference it in client-side code (such as JavaScript). Set to an alphanumeric string.

  • STYLE—Inline style indicating how to render the contents of the <FORM> element.

  • TARGET—Indicates a named frame for the browser to display the form results in. See the section "Using Named Targets" tomorrow.

  • TITLE—Holds additional information (as might be displayed in tool tips) for the element. Internet Explorer only.

The important attributes of the <FORM> element are coming up next.

The ACTION Attribute

You use the ACTION attribute to specify where the data in the controls in a form are sent to when the form's submit button is clicked. For example, to send the data in a form to http://www.starpowder.com/jsps/jsp1.jsp, you would set the ACTION attribute to that URL:

<FORM NAME="form1" ACTION="http://www.starpowder.com/jsps/jsp1.jsp" METHOD="POST">

You can also specify a URL relative to the directory the current document is in. For example, to send a form's data to jsp1.jsp in the same directory as the current document, you can set the ACTION attribute this way:

<FORM NAME="form1" ACTION="jsp1.jsp" METHOD="POST">

You can also omit the ACTION attribute. If you do, the data in the form is sent back to the exact same URL as the current document.

The METHOD Attribute

The METHOD attribute enables you to specify the way you send the form's data back to the server. There are two possible settings for this attribute—GET and POST, and JSP can handle both.

If you use the GET method, the data in the form is treated as text and appended to the URL that the browser navigates to. The server will decode that data appended to the URL and pass it on to our JSP code.

For example, say that you have two text fields in a form, and that you've named these text fields (using the NAME attribute of the <INPUT TYPE="TEXT"> element) text1 and text2, to let the user enter his first and last names:

<FORM NAME="form1" ACTION="http://www.starpowder.com/jsps/jsp1.jsp" METHOD="GET">
  First Name:
  <INPUT TYPE="TEXT" NAME="text1">
  Last Name:
  <INPUT TYPE="TEXT" NAME="text2">

If the user enters Ralph in text1 and Kramden in text2, and then clicks the submit button, this is the kind of URL the browser will navigate to:


This way certainly works, but it's not exactly private—all your form's data is out in the open.

You can also use the POST method, which works just as well as GET as far as we are concerned, but encodes the data as part of the actual Hypertext Transfer Protocol (HTTP) request sent to the server. This means that the data is not visible to the user in the browser. There are no real disadvantages to using POST, except perhaps that you can't bookmark POST URLs and expect any needed form data to be sent when you open that bookmark (as will happen if you use a GET URL). As far as we're concerned, JSP can handle either GET or POST, so there's very little difference for our code here.

The TARGET Attribute

The <FORM> element's TARGET attribute enables you to specify where the results sent back by the server will appear. By default, when you click the submit button and the server sends back a new Web page, the new page replaces the current page. However, you can display the new Web page in a new window if you prefer, by setting the TARGET attribute to _blank. Here are the predefined values you can use for the TARGET attribute:

  • _blank—Display a new page in a new blank window.

  • _parent—Display a new page in the parent of the current frame.

  • _self—Replaces the current window's content.

  • _top—Replaces the current contents of the entire browser window.

You can also display the new Web page sent back by the server in a named HTML frame; you'll see an example of this tomorrow.

Page 1 of 4

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

By submitting your information, you agree that developer.com may send you developer offers via email, phone and text message, as well as email offers about other products and services that developer believes may be of interest to you. developer will process your information in accordance with the Quinstreet Privacy Policy.


We have made updates to our Privacy Policy to reflect the implementation of the General Data Protection Regulation.
Thanks for your registration, follow us on our social networks to keep up-to-date