Steven Disbrow is the owner of EGO Systems, a computer consulting firm in Chattanooga, Tennessee. He can be contacted at email@example.com.
1 This time, we're going to use these concepts along with some new
THE oRadio OBJECT
HTML radio buttons are like check boxes that are kept in herds. Radio buttons are organized into
"families," and only one radio button in each family can be on at any given time. The main
all you need to manage an entire family of radio buttons no matter how many buttons are in the
family. For example, if you have 100 radio buttons organized into two families of 50 buttons
shows the complete source code for the oRadio object.—all
listings from this article are available at Java Report Online only.) If you look at the
constructor function, you'll see that, as with our check box object, we have two instance variables,
"form" and "name,"
to keep track of the form our control is on and the name of the control. After that, we have
six methods for working with our radio button control.
The first method, getLength, is simple enough. It tells us
how many radio buttons are in our family simply by reading the length property that is built
into every radio button family. We use the eval method to actually execute the statement that
gets the length for us. (see June installment for further details.2)
The getSelected method tells us the index of the currently
selected radio button in our radio family. Because radio button families are treated as arrays
of each radio button. If checked is
true, we've found the selected button.
(The setSelected method is pretty much the reverse. You
specify the index of the radio button you want selected, and its checked
property is set to true.)
The next two methods, channelUp and
channelDown, use the getSelected
and setSelected methods to let you cycle through a family of
radio buttons just as you would the channels on a television.
Finally, the getValue method returns the value attribute that is
associated with the currently selected radio button.
Looking at the code in Listing 1, you might notice that in the "onClick"
handler for each button, we are using the setTimeout method
(with a delay of zero milliseconds) to make the actual call to the method for our
you cannot call a method directly from an onClick handler.
However, you can call setTimeout, and it has no problem at all calling
a method. (Of course, setTimeout is itself a method belonging to
the window object, so this problem appears only to affect the methods of user-created objects.)
THE oSelect OBJECT
contains the source code that defines our oSelect object.
The constructor function should look very familiar and in fact, most of the methods are similar in both
name and function to those found in the oRadio object. For example,
the getLength method is almost the same. The main difference
here is that we must access the options array that is built into every selection list in order to
get our information. (This trend continues through most of the oSelect
One difference between radio buttons and select lists is that select lists have a
selectedIndex property that will tell you exactly which item in
the select list is selected. This comes in very handy for the
oSelect getSelected method, but it's completely useless for
the setSelected method. Unfortunately, you can't change the
item selected just by assigning a new value to the
selectedIndex property. Instead, you have to
assign a true to the selected
property of the item you want selected.
One final difference between radio buttons and select lists is that each item in a select list has both
a value and a string of text associated with it. The value is a bit of internal information for that
list item and the text is what is actually displayed to the user. Both are simple properties, so
the getText method is very similar to the
getValue method. The only difference is that instead of
retrieving the value property, we retrieve the
THE oText OBJECT
So far, most of the "enhancements" we've looked at have been for ease-of-programming. They really
haven't added any new abilities to our HTML controls. This last example does.
validation rules right into our text boxes. The source code for just such a thing is shown in
As you can see, the constructor for this object is a bit more complicated than others we've seen.
The first few lines are simple enough: We define three instance variables and three methods. The
first two instance variables are our standard form and
name variables. The third, dataType,
is used to track what type of data we want to allow in this text box. This is set by the
tType parameter that we pass to the constructor function.
After we define our methods, we actually define another instance variable,
validChars. This variable will hold a list of characters
that we want to allow in this text box. In addition to the three pre-defined sets of characters
and "hex"), you can specify additional valid characters
by passing them in the moreValidChars parameter. Note
that the different type codes ["hexType," etc.] are
defined as "constants" elsewhere in the source code.
So, let's look at the isValid method and see how it makes use
of validChars to check the contents of a text box. As you can
see, this is actually pretty simple. First, we make sure that we should in fact do any checking
at all by comparing our data type with the anyText constant.
If any text is allowed, we simply return true to the
caller. Otherwise, we get the text from our control using the getText
method [which, along with the setText method is, hopefully,
easily understandable at this point] and, using a for loop,
check each character of the text to see if it can be found in our list of valid characters. If a
character can't be found, we present the user with a dialog saying that what they have typed is
invalid and we then set the focus to the field in question.
The last thing we need to discuss is the way these methods are invoked. Looking at the HTML for
the "Enter an Integer String:" text box, you can see that this text box has
an "onChange" handler that calls the
isValid method for this text box object when the value
in the text box changes. (You might also want to check each box inside
an "onSubmit" event handler.) That's all there is to it!
REALLY, THAT'S IT!
is easy and, more importantly, a very useful skill to have. With just a bit of imagination, you
can use these same techniques to make your HTML pages much more versatile. If you come up with
- Disbrow, S., "Your own private Idaho()," Java Report, Vol. 4, No. 4, Apr. 1999, pp. 66-69.