By Charlie Arehart | Article Rating: |
|
January 1, 2002 12:00 AM EST | Reads: |
43,424 |
.jpg)
Many new J2EE developers get caught up in focusing on the details and nuances of servlets and JSPs and, as a result, may not learn how to leverage JavaScript. Some may even dismiss it as too much hassle, given cross-browser compatibility issues.
For both audiences there's still value in learning at least a minimal amount about client-side scripting. Even learning about just one feature - setting the cursor on the first form field you may have - can bring measurable benefit to your site visitors.
In this month's Journeyman J2EE, we depart from pure J2EE topics to address this subject, which should be understood by any Web application developer. If you're a newcomer to JavaScript, I'll provide more than enough to get started.
Where's Your Focus?
Here's the motivation for the problem I want to solve: you
visit a Web site that offers a form inviting you to enter some input.
No big deal - we see them all the time, right? Now, how do you get to
the point of entering data into that first field?
Do you use your mouse to move the cursor to that first data entry area? Or are you a keyboard maven, like me, in which case you prefer to tab to such a field? The problem is you may have to hit the tab key several times before you can enter data.
Indeed, it's typical to visit sites with navigational toolbars across the top and/or left side of the form, forcing you to tab dozens and dozens of times. It's an annoyance, especially if visitors to your site know the site designer could have easily prevented the problem.
If you think that's being pedantic, consider a simpler example. If you show users a page that clearly is expecting them to enter some data (perhaps a user ID or a search argument, etc.) before proceeding, why not put the cursor right on the data entry field rather than forcing them to use the mouse or keyboard to get there. It's a usability issue.
There's an incredibly simple solution. Just the tiniest bit of JavaScript is needed, a single line of code, really. This article shows how to use it and also lays the most basic foundation for using JavaScript, if you're new to it.
Laying the Foundation
The technique we're talking about involves putting the
"keyboard focus" on whatever form input field - a text, password, or
textarea box or even a radio, checkbox, or select field - you want
the user to enter data into first. The solution is the JavaScript
"focus" method.
The JavaScript language is available to any Web page designer on nearly all Web browsers. (Microsoft calls its version of the language JScript. They're nearly the same, especially for the purposes of this article.) It's a scripting language that can be used to add features to your Web page that aren't otherwise provided by HTML.
This article shows you the simplest application of this focus method. It's pretty straightforward and should work fine in most instances. JavaScript is widely supported by most browsers now, and this particular feature is supported identically in both Netscape's and Microsoft's versions of the language, so there's no need to worry about it breaking on different browsers.
Gimme the Goods
We need to put this method in some JavaScript code inside our
page. If you haven't coded JavaScript on your pages, there are
several ways to do this. You can embed the code in a pair of <SCRIPT>
tags (and even then you have choices about where those tags are
placed) or you can place it in special attributes of HTML tags (such
as ONLOAD within a <BODY> tag).
Let's take a simple example in the first of those two forms. We can use the JavaScript alert() method to cause a message to be displayed to the user in a popup box. To do that, we could use the following code:
<SCRIPT LANGUAGE="JavaScript" TYPE="text/javascript">
alert('Hello World');
</SCRIPT>
Focus on Forms
The focus() method operates on form fields. One of the many
powers of JavaScript is that not only can we refer to (display, test)
all the elements of our page (all the forms, form fields, indeed
every tag and its contents and attributes), we can manipulate them as
well.
How do we specify that we intend to work with some part of our page, such as a particular form field? Most of you know that you can give a name to a form field, and in JSP/servlets that will become the name of an attribute in the request scope on the form's action page. In our JavaScript we can use that same name to refer to the form field to give it focus. If we have an input field for a "UserId" that should be entered, the HTML would be:
<FORM ->
-
Enter Userid: <INPUT TYPE="text" Name="UserId">
-
</FORM>
One reason it's important (besides being the way HTML is coded!) is that when we want to refer to a particular element within a Web page from within JavaScript, we need to refer to it in the form of its relationship to the entire page. This input form field, "UserId", occurs inside of a form. On a simple level we might refer to it as form.UserId.
This isn't technically correct, however, since it's possible to have more than one form in a page. Indeed, there are rules that describe how to refer to elements on a page within JavaScript. It's called the Document Object Model (DOM). In any case, we need to indicate the specific form in which the field occurs.
What's in a Name?
There are two ways to do this: we can refer to the form by
name or by indicating the relative location of the form on the page.
Which is appropriate for you depends on your situation. If you've
specified a NAME attribute on the <FORM> tag, you'd use that name.
If we had specified NAME="Login" on the <FORM> tag, we would refer to the form field as Login.Userid. But we're not done yet. The form itself occurs within the Web page, and while it might not seem necessary, the contents of the page are considered to be within the "document" on the page (again, recall the "Document" Object Model). We finally have the complete means by which to refer to the field: document.Login.UserId.
Before leaving this subject, let's clarify that if you haven't named your form, you can still refer to it by indicating the relative location of the form within the document. There's a special "forms" array in every Web page document, so if you have only one form in yours, you would indicate it as the first form.
Unfortunately, even this can trip you up because in JavaScript (as in Java) you start counting lists of elements at 0 rather than 1. So the way to refer to your form field (assuming it's within the first or only form on the page) would be:
document.forms[0].UserId
Notice that this isn't used as "form[0]" but as "forms[0]". It's a subtle point, but if it's not specified correctly, you'll receive an error.
We're on the Case
Indeed, it's also critically important to remember that
JavaScript is case-sensitive. The case you choose when naming
something must be the case you use when referring to it later with
JavaScript.
If we were to refer to our form field as Document.Forms[0].UserId, for example, we'd get an error. JavaScript expects us to refer to both the "document" and "forms" elements as all lowercase.
Similarly, since we named the form field UserId, we must refer to it exactly that way. If we referred to it as document.forms[0].userid, or even document.forms[0].Userid, we'd receive an error either way.
Forcing the Focus()
To set the focus we use the focus method just like a
reference to an object's method in Java. To set the focus for our
form field called "UserId", we might specify it as:
document.forms[0].UserId.focus()
That's about it. There's nothing to be specified within the parentheses. (Notice that the word focus is also all lowercase.) This statement, when executed, will cause the named field in the named form to receive the focus when the page is displayed to the user. In other words, the cursor will be resting on that field when the page is loaded.
Our final challenge is to decide where and how to specify this statement. Of course, it's JavaScript and must be specified to be executed as such. We mentioned earlier that this could be done by way of the <SCRIPT> tag. The following code will cause the focus to be placed on our UserId field:
SCRIPT LANGUAGE="JavaScript" TYPE="text/javascript">
<!--
document.forms[0].UserId.focus()
//-->
</SCRIPT>
There are other ways to specify JavaScript within a page. Besides the <SCRIPT> tag, we can also use the event-handler attributes of other tags. For instance, we could also force the JavaScript to execute only after the entire page has loaded. Some may know that there's an attribute for the BODY tag called ONLOAD that does just what we need, causing whatever statements it executes to be run only after the page has loaded. Since the form is within the page, this is indeed another solution to our problem.
Fortunately, we can easily specify our JavaScript statement (the statement itself, not the <SCRIPT> tags) by placing it in the BODY tag's ONLOAD attribute, as in:
<BODY ONLOAD="javascript:document.forms[0].
UserId.focus()">
Pretty nifty! (The "javascript:" directive preceding the statement is not usually required, but it's the formal method of specifying JavaScript within an attribute like ONLOAD.)
Experienced developers may prefer yet another approach: creating a function instead and calling that function in the ONLOAD.
But Will It Fail?
You should have no trouble if you:
- Specify the JavaScript statement using one of the two appropriate approaches.
- Refer to the form field using the naming references indicated.
- Remember to specify the proper case for the naming reference.
- Ensure that the statement occurs only after the form has been loaded.
In a similar vein, and equally tricky in some situations, you don't want to include the JavaScript statement on the page if the form field to which it's referring isn't included in the page. With dynamically built pages as in JSP and servlets, this isn't as strange as it might seem. Forewarned is forearmed.
What if a user's browser simply doesn't support JavaScript? There's very good news.
With the <SCRIPT> tag approach described earlier, you may notice that just inside the opening and closing <SCRIPT> tags are HTML comment tags. This is a standard JavaScript approach that guarantees that if the browser doesn't support the <SCRIPT> tag (which it will simply ignore), it will also ignore the JavaScript statements inside the script and comment tags. However, browsers that support JavaScript still execute the statements inside the comment tags.
With the ONLOAD approach as well, browsers that ignore JavaScript also won't recognize JavaScript-related attributes. The ONLOAD attribute is purely and simply for executing JavaScript and hence is ignored by non-JS browsers. By association, the value specified for that attribute (our JavaScript statement in the second approach) is also ignored.
Some Caveats
Should you go ahead and add the focus method for the first
input field of the forms in all your pages? Well, first it may not be
appropriate to the interface. On some pages the form and its input
fields may not really be the focus of the page. Consider a page that
happens to have a search field on it, such as
http://industry.java.sun.com/solutions/ (see Figure 1).
If you look closely at the top right corner, there is indeed a "form" on this page for searching the site, but it's definitely not the focus of the page. There's also a search field to "Find a Solution" on the right-hand side. Should we put the focus in the first form field? The second? Either? Maybe neither. If you put it on the second, which may seem a focus of the page, keyboard users would find that tabbing once wouldn't take them to the top nav bar but instead to the links under that search field. That's not good usability, either.
Another reason not to blindly set the focus on any first form on the page is if the form doesn't appear at the top of the page. If we did that, an unintended result would be that the screen would be scrolled down when displayed, so that the field with focus (that form input field) was visible. This may cause the top of the page to be hidden from the user. Remember, too, that users often have different (and lower resolution) monitors than developers, increasing the chances of this problem developing. It can also happen if the users don't maximize their screen when displaying your page.
When would it be appropriate to put the focus on a field? When the form is clearly the focus of the page. Going back to the previous example at Sun's Solutions Marketplace, consider the link under that "Find a Solution" button, labeled "Enroll Your Company." On the page that will be shown, it prompts for Company Name. That's clearly the focus of the page, so putting the focus on that field would make sense (sadly, they're not setting the focus using this approach as of this writing).
If you visit www.altavista.com, a popular search engine, you'll see that searching is clearly the focus of the page, and they do indeed use the focus method so that you can start typing search criteria as soon as the page appears.
Another natural example, and one that nearly all developers end up dealing with, is a login page that's presented to enter a site or access secured areas. If the user can't proceed without entering a user ID/password and the prompt for this is the only reason the page is being presented, there's little reason not to set the focus on the UserId field.
Afterword: Using SCRIPTJ in JRun Studio
There's one last useful trick that will be of interest to
users of JRun Studio (a similar feature may exist in other IDEs). It
also works in its sister Macromedia products, ColdFusion Studio and
HomeSite.
Remember <SCRIPT> tags offered earlier with the HTML comment characters specified within them - I mentioned that these are a standard set of tags to be used for all JavaScript entered within a page (other than that entered within other tag attributes like ONLOAD).
You could hope to remember to enter that properly formatted set of basic tags:
<SCRIPT LANGUAGE="JavaScript" TYPE="text/javascript">
<!--
//-->
or you could take advantage of a nifty shortcut in Studio: simply type SCRIPTJ, press CTRL-J (the control key and J), and watch as Studio converts that into the set of tags offered above. The cursor is even sitting there within the paired tags waiting for you to type in your JavaScript. (Hey, now there's a great use of cursor focus!)
Summary
Using the focus method is a win-win that should be used in
many Web forms. JavaScript is ignored in browsers that don't support
it or have it turned off, and being a JavaScript 1.0 element it works
even in Netscape 2 and IE 3. Plus, it really is just a single
statement of JavaScript code in nearly all cases. Now do you see why
I find it so frustrating when a site doesn't use it? I hope newcomers
to JavaScript have also learned a few things.
Published January 1, 2002 Reads 43,424
Copyright © 2002 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.
More Stories By Charlie Arehart
A veteran ColdFusion developer since 1997, Charlie Arehart is a long-time contributor to the community and a recognized Adobe Community Expert. He's a certified Advanced CF Developer and Instructor for CF 4/5/6/7 and served as tech editor of CFDJ until 2003. Now an independent contractor (carehart.org) living in Alpharetta, GA, Charlie provides high-level troubleshooting/tuning assistance and training/mentoring for CF teams. He helps run the Online ColdFusion Meetup (coldfusionmeetup.com, an online CF user group), is a contributor to the CF8 WACK books by Ben Forta, and is frequently invited to speak at developer conferences and user groups worldwide.
Feb. 17, 2019 02:00 AM EST |
By Elizabeth White ![]() Feb. 16, 2019 04:45 PM EST Reads: 14,062 |
By Zakia Bouachraoui Feb. 16, 2019 04:00 PM EST |
By Zakia Bouachraoui ![]() Feb. 16, 2019 03:30 PM EST |
By Yeshim Deniz ![]() Feb. 16, 2019 05:45 AM EST |
By Yeshim Deniz Feb. 16, 2019 03:15 AM EST |
By Pat Romanski Feb. 16, 2019 12:15 AM EST |
By Roger Strukhoff Feb. 14, 2019 05:00 PM EST |
By Elizabeth White Feb. 13, 2019 08:15 PM EST |
By Liz McMillan Feb. 13, 2019 06:45 PM EST |