The World Wide Web has grown and flourished through the use of the HTML standard, as is evidenced by the large number of attractive HTML pages accessible from your browser. However, as the Web has become more sophisticated, limitations in the HTML standard have become increasingly apparent.

The major problem with HTML is that it isn't dynamic. The conventional HTML page can't truly interact with the Web user. Once a browser has interpreted and displayed an HTML page, the page can't change.

Wait a minute, you say. What about search engines that search the Web for keywords entered into an HTML page by the Web user? How is that done? There are a number of ways that user interaction can be simulated in an HTML page.

Adding User Interaction to Conventional HTML Pages

Web-based search engines, such as Yahoo , make it clear that HTML includes features that make an HTML page appear to be dynamic. What are the techniques that HTML page developers use to animate their Web sites? This section focuses on the answer to this question.

applet

Java applets can of course implement user interaction, as was demonstrated in Chapter 14, , and Chapter 15, . A Java applet is started by an HTML page and the applet runs within the browser. Because a Java applet is an app, it can interact with the user in a number of ways. In addition, a Java applet can change its appearance after the HTML page has been displayed.

The major limitation of any applet is that its window is carved out of the HTML page. A Java applet doesn't look like it's part of the HTML page that surrounds it, because a Java applet doesn't play by the same rules as an HTML page does. For example, when the user changes the size of the browser window the Java applet isn't resized like the other HTML objects on the page. In addition, a Java applet can't access the surrounding HTML page. Unless an applet uses scripts, it can do nothing to change the appearance of an image or a field on the HTML page display.

CGI apps

CGI (Common Gateway Interface) is an extension to the browser-to-server interface that defines an interactive-although not dynamic-interface. The HTML standard supports CGI by a feature known as forms, identified with the <FORM> tags.

A form defines a span within the HTML page, and also defines an attached URL link. Any number of standard HTML elements can be placed between the <FORM> tags, and the browser renders these elements within the form, just as it would render elements outside the form.

A form can also include user input fields. Each input field carries a name and can be one of various types. Input field types include buttons, check boxes, drop-down list boxes, and text entry fields, to name a few. Each input field also has a value. The possible values for a given input field are determined by the type of field it is. For example, the value of a button is either on or off, and the value of a text field is the text entered by the user.

One and only one of the input fields in a form must be a Submit button. (The label on this button doesn't have to be Submit, but it normally is.) When the user chooses the Submit button, the browser links to the URL address indicated in the form, and sends the URL to the server. Unlike conventional hyperlinks, however, the browser adds to the end of the URL the name and value of each of the input fields defined for the form. This tells the server what values the user entered into each input field.

The URL listed in the form doesn't refer to an HTML page on the server. Instead, the form's URL refers to an app on the server. When the server receives this app link, it passes the data the user entered to the app referenced by the URL. (The details of how this data is passed to the app aren't relevant to this discussion.) The app creates a new HTML page based on the user's input, and sends it back to the server. The server then passes the new HTML page to the browser for display. The browser is unaware that the displayed HTML page was generated by an app rather than by an HTML file.

The CGI concept is extremely powerful. As a CGI programmer, you can create any type of browser output you want in real-time, based on user input. However, the limitations of the CGI interface are numerous. For example, CGI apps are difficult to write, and CGI apps can't save their state from one query to the next.

The most serious problem with CGI, however, is that CGI apps put a significant load on the server. Every CGI request causes the server to begin running an app to process the query. Once the request has been processed, the server must pass the results back to the HTML page and terminate the app. When a large number of concurrent CGI requests occur, the constant starting and stopping of server apps can cause unacceptable delays for the user.

Scripting languages

Netscape addressed some of the difficulties inherent in CGI by defining an HTML scripting language called LiveScript, which was later renamed JavaScript. (The name change to JavaScript was driven more by commercial factors than by any similarity between JavaScript and the Java language.) Microsoft responded with its own version of JavaScript, which it named JScript. (JavaScript and JScript are almost completely compatible.) In addition, Microsoft implemented a completely different scripting language called VBScript, which is based on Microsoft's app macro language.

Script languages enable you to preprocess form data before sending it to the Web server for CGI processing. This preprocessing allows the scripting language to catch obviously incorrect user input, such as no text in a required text input field.

Catching invalid data before sending it over the Web for processing improves the response time to the user and reduces the load on the server. Preprocessing data ensures that the user doesn't wait for a CGI request to make the round trip to the server and back, only to find out that an entry was incorrect. In addition, with preprocessing the server isn't loaded down with erroneous CGI requests.

Although scripting languages can read and process user input before passing it to the server, they have a serious disadvantage. Once the browser has rendered the HTML page, scripting languages are powerless to change the page without server assistance.

DHTML Capabilities

DHTML extends HTML by allowing an HTML page to be modified after the browser has rendered the page. For example, with DHTML, a text field that says "Stopped" when the page is first displayed can be changed to say "Started" when the user clicks a "Go" button. You can make a clock in an HTML page tick automatically, whether the underlying HTML includes a clock directive or not. (DHTML also extends features such as style sheets; however, the focus of this chapter is active changes in the HTML page display.)

DHTML increases the capability of scripting languages immensely. With DHTML, you can use script to implement many coding features that previously required CGI, while at the same time reducing the HTML page response time. In the previous example of changing the contents of a text field from "Stopped" to "Started," the HTML page spends no time requesting a new HTML page from the server and displaying it. The display change is instead made directly by the HTML page. Avoiding CGI requests reduces the time a page takes to respond to user input, and lessens the load on the server.

DHTML also enables you, as a script programmer, to implement features that are impossible to implement with CGI. The CGI app doesn't receive input until the user clicks the Submit button. By comparison, DHTML-based scripts can receive and process an event when the user clicks any button or even when the mouse pointer passes over a button.

While DHTML increases the capability of scripting languages, it does nothing to address other problems inherent in scripts. Because script languages lack the clear structure of Java (or other languages such as C++), scripts of more than a few dozen lines become difficult to write and debug. (Some programmers claim that 100 lines represent a practical upper boundary for a script app.) In addition, script languages have a long learning curve that the Java programmer must surmount.

Visual J Plus Plus Access to DHTML

Visual J Plus Plus introduces the ability to access the capabilities of DHTML from a Java app. Your control of DHTML features no longer requires you to learn a new scripting language. Your control of DHTML features can also be more sophisticated than before, because Java apps can be larger and more involved than apps written in a script language. In addition, Java access to DHTML introduces capabilities that aren't supported by scripting languages, such as access to database information on the client (the browser) or the server.

DHTML access in Visual J Plus Plus is contained in the Windows Foundation Classes for Java (WFC) wfc.html package. Visual J Plus Plus source code that accesses the html package looks amazingly like the code that accesses other WFC objects. The same Visual J Plus Plus app can use the html package on the client or the server with only minor changes.