JavaScript, though still not completely solid, offers help for making clients smarter.
Jon Udell
When Rex Baldazo wrote an installment of this column back in August 1996 (
http://www.byte.com/art/9608/sec9/art1.htm
), he concluded that JavaScript was "a frustrating work in progress." I agreed and held off deploying JavaScript on The BYTE Site. Because JavaScript was buggy and not universally available, I've kept our site in pure HTML mode --
until now.
Times change. JavaScript today is less buggy and more available. I can't give it an unqualified thumbs-up yet, but now there are some compelling reasons to use it. JavaScript (like its isomorphic cousin, VBScript) is really a natural extension of HTML. When you load a page with JavaSc
ript enabled, the browser reflects all the objects on the page -- frames, links, form widgets -- as a corresponding set of JavaScript objects.
The result is an HTML page with extra smarts. Scrolling marquees are a silly way to use that intelligence. Site navigation and form validation, on the other hand, are two extremely practical uses, which I'll explore this month.
BYTE Site Finder
I've replaced many of the static links on our home page with a JavaScript-aware pick list. You've seen lots of these around on the Web -- an HTML SELECT widget coupled with a "go" button. Drop down the list, pick the area you want, and click on go to load the page. It'
s a nifty way to conserve precious screen real estate; I may even regenerate our on-line archive to include an instance of this widget on every page.
This jump widget doesn't require JavaScript. You can do it in straight HTML, with the help of a CGI script (see the figure
"Finder version 1: Pure HTML/CGI"
). The advantage of this approach is that it's guaranteed to work for everyone -- even those using Microsoft Internet Explorer (MSIE) on the Macintosh or Lynx. The disadvantage is that you saddle the user with an extra round-trip to your server, and the server with an extra bit of work.
The whole point of distributed computing is to use the CPU that's closest to hand, if it can meet the need. Yes, you can refer users back to your server, which can run a program that can send back the address of the next page. But should you? Client intelligence exists so that you can do these things locally.
The figure
"Finder version 2: Pure HTML/JavaScript"
shows
the first version of the JavaScript-aware Finder. Notice that there's no go button, only a drop-down listbox. Why no button? I realized that there were two ways to wire JavaScript to the listbox. You can write a handler for the form's
onSubmit
event; it will run when the user clicks on the go button. Or you can write a handler for the listbox's
onChange
event. In that case, you can skip the button entirely and save the user a mouse-click.
The no-button approach was elegant, I thought, but users were quick to point out its flaws. "I have two concerns," wrote Brett Musser. "First, you need an alternate access route for those people who don't run JavaScript; second, people aren't used to pop-up menus causing actions." He was right on both counts. Although my stats indicate that over 90 percent of our audience runs JavaScript-capable browsers, you can't simply write off 10 percent of an audience. Furthermore, as Alan Shutko noted, "You're assuming that we turn on JavaScript." He doesn't,
because he's concerned about security (see the sidebar "Could JavaScript Steal a Cookie?").
The final solution (see the figure
"Finder version 3: Hybrid CGI/HTML/JavaScript"
) was a happy compromise. To support the non-JavaScript crowd, the button had to be there. Was it possible to overload the button so the page would give JavaScript first crack at handling it but fall back on CGI if necessary? Yes. You need only migrate the
gotoUrl
function call from the SELECT widget's
onChange
handler to the form's
onSubmit
handler. The trick is this: The
onSubmit
handler must return false to preempt the button's CGI script.
Now everybody's happy. JavaScript users get quick response, and the non-JavaScript folks get the same result a bit more slowly.
Frame Navigation
In last December's column (
http://www.byte.com/art/9612/sec9/art2.htm
), I demonstrated how to use HTML to create a two-pane, frame-based display that's synchronized in both directions. You can see this at work in the Web views of our site's conferences. Clicking on links in the index pane loads the message pane, as you would expect. Clicking on Next and Prev in the message pane causes the index pane to synchronize to the current message. (This is something that you might not expect, but I think it's nifty.)
In the original solution, my HTML generator created not only a unique frame page per message, but also a corresponding unique frameset page per message. This was wasteful because it created a large number of little files, but manageable because it was all automatic.
The problem was that it was always necessary to reload the whole frameset. This created an annoying flicker, but it was otherwise OK, so long as the index page stayed in cache. B
ut the conferences outgrew that method, and the index began to tediously reload on every Next or Prev action.
The answer? JavaScript to the rescue, as one reader wisely suggested. I stuck with my original solution as long as I did because it was 100 percent pure HTML, and thus browser-independent. But that became counterproductive. I decided to tweak the HTML generator to emit the JavaScript that's needed to reposition the index when you click on Next or Prev from a message page in frame view.
Here's how the old Prev link worked:
<a href="fi001.html"
target="_top">[Prev]</a>
If you clicked on this link from message 2, the frameset for message 1 would replace the entire contents of the browser's window. Here is that frameset:
<frameset cols="35%,*">
<frame src="fthreads.html#001"
name="indexpane">
<frame src="fmsg0001.html"
name="docpane">
It means, "In the index pane, load (hopefully from cache) t
he index page and then set message 1's header to top-of-frame. Load message 1 itself into the document pane."
Here's the new Prev link:
<a href="fmsg001.html"
onClick="parent.indexpane
.location='fthreads.html
#001'">[Prev]</a>
It means, "Load message 1 into the current (document) pane and tell the other pane to set message 1's header to top-of-frame."
This way is subtly different. Now there is only one document being fetched and loaded -- the new message. The frameset page remains, so it's possible to reposition it without causing any disruption.
Unlike the Finder, this new feature is not transparently available to non-JavaScript browsers. Those users just won't see any adjustment of the index pane when they move forward or backward using the document-pane controls. Since many people probably wouldn't expect that behavior anyway, I lazily argue that it's OK to not support it in the non-JavaScript case.
Data Validation
In our January cover story, senior editor Tom R. Halfhill discussed OscarCalc BallotMaker, a Java applet that he wrote to collect entries for his yearly Oscar-awards contest. When Tom asked me to host the applet on The BYTE Site, I asked, "Why is this a Java applet?" The applet presents forms, validates them, and stores data for later analysis.
HTML/JavaScript offers a simpler, faster way to get the same job done. Tom wrote the applet primarily to learn about Java-based GUI programming, and it was useful in that regard. But after I hosted the applet on our site, I decided to compare the Java solution to an equivalent HTML/JavaScript solution.
I had always relied on CGI for validation, never JavaScript. The JavaScript code to validate the HTML/JavaScript BallotMaker is quite simple because the bulk of the validation can be accomplished by iterating through the elements array in which JavaScript enumerates the form's 24 SELECT widgets.
What should have taken a few minutes, however, st
retched to over an hour. Why? A Navigator 3.0 bug. On my first attempt, I wired the
validate()
function to the form's
onSubmit
event without passing any arguments. Inside the function, I referred to the form's elements using fully qualified names (e.g.,
document.oscarform.elements[0].options.selectedIndex
). This should have worked -- and, in fact, it does work in MSIE -- but it confused Navigator horribly. What finally did work was to pass a reference to the form as an argument to the
validate
() function.
Squirrelly behavior like this prevents me from recommending JavaScript wholeheartedly. Nonetheless, when JavaScript is an appropriate solution, it makes sense to use it.
The HTML/JavaScript version of BallotMaker is far simpler than the applet version. There's an irreducible minimum amount of information required for BallotMaker (or any form-based application). That information is the form itself. Since BallotMaker's job is merely to display the form and transm
it its results, the optimal solution adds as little coding as possible to what's required to create the form itself. The BallotMaker applet's HTML wrapper uses a long list of
<param>
statements to define the form widgets that the applet renders. These add up to nearly the complexity of the HTML/JavaScript form.
Then there's the applet itself -- a chunk of Java code to render the widgets and send their output. In the HTML/JavaScript case, once you've enumerated everything in the form, you're done: You've got the data-collecting and data-transmitting widgets. No need for a separate program to do that.
The public Web applications that I rely on to do my daily work, as well as the ones I create, expect no client-side intelligence. Java can deliver a lot of local smarts, but today you and your users pay a price: slow development and heavy resource drain. JavaScript creates an important middle ground. It delivers enough local smarts to solve certain important problems -- notably navigatio
n and form validation -- yet plays comfortably to the majority of the installed base.
TOOLWATCH
WebRecord................$29.95
Canon
Internet:
http://www.ccsi.canon.com/
A terrific solution to the problem of printing Web pages. WebRecord reduces pages to fit two-up or four-up, superscripts the links, and appends an index that documents the addresses behind the links.
BOOKNOTE
Client/Server Programming with Java and CORBA
............$44.95
by Bob Orfali and Dan Harkey
Publisher: Wiley Computer Publishing
Internet:
http://www.wiley.com/compbooks/
When the new Netscape clients and servers hit the streets, there will be a stampede for information about how to use the embedded Java ORB. Here's the tutorial you'll want. It's an authoritative discussion of Java-based CORBA programming vis-à-vis sockets, CGI, RMI, and ActiveX/DCOM, plus lots of sample code.
illustration_link (53 Kbytes)
photo_link (30 Kbytes)
Jon Udell is BYTE's executive editor for new media. You can reach him by sending e-mail to
jon_u@dev5.byte.com
.
JavaScript Revisited
