Elements of Client-Side Scripting
The previous article in this series began our introduction to client-side scripting, a technology for adding greater interactivity to Web applications through lightweight programs that run in the browser. This article continues with an introduction to the primary components of client-side scripting.
These essential elements work together to enable the creation of exciting, full-featured Web applications:
- The runtime environment
- The browser API
- The document object model
- Scripting languages
The Environment: Scripts in the Browser
A scripting engine is software that parses and executes program commands. Modern Web browsers contain a scripting engine that is used to run scripts that are downloaded from the server along with a Web document. The script code itself is plain text and is an integral part of the HTML document. The browser application on the client is responsible for identifying, parsing, and executing the code. There are a couple of ways that the browser can distinguish script code in the document from content meant to be displayed: first, by encountering a <script> tag in the document, and second, by finding in-line code that has been associated with an document element and event in that element's attribute list.
The <script> Tag
As the browser loads the HTML, it might encounter a <script> tag. If so, the browser treats everything between the <script> tag and the next encountered </script> tag as executable code. The browser uses the language specified in the language attribute for the tag, or the default language, if the attribute was not specified. The browser then instantiates the appropriate scripting engine and passes in the code. The script processor evaluates and compiles this code and then executes it in the browser's process.
Listing 1: Client-Side Script Delimited by the <script> Tag
An event is a message or notification sent to the script that indicates that some action has occurred or some state has changed. This is usually to inform the script about user input, such as clicking the mouse or pressing a key. An event can be specific to an individual element, such as an event that occurs when the mouse cursor moves over a certain image. However, events can also be relatively general, applying to the document or browser as a whole, such as the event that occurs when the document has finished loading into the browser.
Programmers leverage these events to write code that executes in response to user input or changes in state. This code is organized into event handlers: functions or methods that are executed when their corresponding event occurs or is fired. The event handler normally carries out some processing related to the action or state and can optionally raise the same or different events.
Listing 2 illustrates one way in which custom processing can be attached to an event. The onclick attribute is used to specify to the browser what to do when the user clicks the mouse over the button element. In this example, the onclick attribute of the <input> tag has the value doCount();.Because there is a function referenced by this page by that name, this function is executed whenever the onclick event fires for this element.
Listing 2: Binding a Client-Side Script to an Event
Note that the default processing for clicking a button still executes. For example, the GUI still works: The button shading changes so that it appears to have been depressed and released. So, the doCount() functionality supplements the default processing; it doesn't replace it.
A more practical example is given in Listing 3, where a client-side script is bound to a text box and its onkeydown event to limit the data that a user can enter into the text box. Each time a key is pressed when the text box has the focus, the NumCharMask() function is called. This function examines the code of the last key pressed and discards it if it is not a numeric character or a cursor-control character.
Listing 3: Client-Side Validation of Input