Section 6.1. The Event Handler at DOM Level 0
6.1. The Event Handler at DOM Level 0The earliest event system is often labeled Events or DOM Level 0. This earliest, and still most common, approach to assigning new or modified functionality to an object event is through an event handler. An event handler is a property of an object that has the syntax of: onevent Where the event handler starts with "on-", and the event can be load, click, etc. The syntax for adding a JavaScript event handler directly to an object is to attach the event handler name as an attribute of the object tag and assign the code to run when the event occurs. The code can be implemented directly in the handler: <body onload="var i = 23; i *= 3; alert(i);"> More frequently, though, a function is called: <body onload="calcNumber( );"> Adding events as an attribute to an HTML element is sometimes known as an inline model or inline registration model. Unlike most functions in JavaScript, event handlers are all lowercase, though if your web page is defined with an HTML DOCTYPE, your browser may accept a Hungarian/Camel notation (mixed upper- and lowercase). However, the mixed-case approach works if, and only if, you invoke the event handler as an attribute on an HTML element: <body onload="calcNumber( );"> <body onLoad="calcNumber( );"> XHTML demands that all attributes be lowercase. As such, you'll want to use the lowercase notation for all of your JavaScript applications. Event handlers can also be accessed directly, as a property, on each object. The following assigns a function to the onload event property of the window object: window.onload=calcNumber; To remove the function, assign the event handler to null. This approach of assigning a function to an event handler that is an object property is sometimes called the traditional model or traditional registration model. Example 6-1 demonstrates both the traditional and inline event models, based on the page load onload event. These are the same events, and you would expect the pop-up window with the message to open twice. Example 6-1. Both traditional and inline event handlers are used to capture load event
The pop-up message of "hello there" displays for the first method but not for the second message. The reason only one pop-up window opened is that only one event handler is allowed for any given event and object. The function assignments are not cumulative. If you want more than one function to be processed based on an event for a specific object, you need to list them in the event-handler codeeither inline or called from one function using the traditional method: <body onload="helloMsg( ); helloTwice( )"> Or from within the code: function helloMsg( ) { var helloString = "hello there"; alert(helloString); helloTwice( ); }The inline events work with all browsers; however, you should restrict their use. The reason is that if you add events to HTML elements, and you change the function name that's called or want to change the behavior of the JavaScript in a bunch of pages, you then have to go into each and manually make the changes. For anything but the simplest sites, this is prohibitive. A better approach would be to use the traditional method, which works with all modern browsers. The best approach is to use the newer event-handling procedures, for reasons detailed later in the chapter.
With some events, such as submit, that are based on the results of running the JavaScript code, you may not want the event to continue its default process. In such cases, you can return a value of false from the event-handler function: function doSomething( ) { // does some code return false; }This signals the browser to terminate the event at that point. You'll see this in action later in the chapter when we move into form processing. For many events, knowing that an event happened is enough, but for others, such as click or mousedown and so on, you might want additional information about the event, such as page location. So the question is, how is this information accessed? That's the next bit of cross-browser event irregularityalbeit fixablewe'll look at next. 6.1.1. The Event ObjectDOM Level 0 events can be split into two camps: the old Netscape camp, which is now subsumed by Mozilla/Firefox, and Internet Explorer. For the most part, getting an interactive page to work with both can be done, but you might have to use a few tricks. One trick is how to get access to the Event object. The Event object is associated with all events. It has properties that provide information about the event, such as location of a mouse click and so on. The Event object actually looks quite similar to both Internet Explorer and Mozilla; a couple of methods differ. However, getting access to the object is drastically different. IE attaches Event as a property of the window object. When accessed as part of event processing, the data it contains is populated accordingly. In Example 6-2, the IE Event object is accessed from Windows when the mouse button is depressed, and the screen X and Y location are printed out in a pop-up window. Example 6-2. Accessing IE Event object
This method of capturing the Event object persists into Internet Explorer 7, as well as the older versions. The Netscape-based browserssuch as Netscape, Firefox, Mozilla, Opera, and Caminoobtain the Event object differently: it's passed as part of the function. In this case, the function to work with a browser such as Firefox looks like: function mouseDown (theEvent) { var locString = "X = " + theEvent.screenX + " Y = " + theEvent.screenY; alert(locString); }A way to handle these cross-browser differences is to test whether an object passed into the function is instantiated. If it is, assign this to a local variable; otherwise, assume the window.event is the event, and assign it to the variable. Example 6-3 shows a cross-browser-compatible version of Example 6-2. Example 6-3. Cross-browser-compatible version of Event object
(Remember a few chapters back how I wrote that the ternary operator is handy for dealing with cross-browser differences? Well, Example 6-3 just demonstrated its usefulness.) The following Event properties are compatible across browsers:
I'll cover the client and screen system in more detail later in the book when we start creating dynamic pages. Testing the control keys is a good way to determine if a certain sequence of keys are pressedeach perhaps leading to a different set of actions. In addition, the key number is handy if you're creating something like a slide show, where you might want to intercept N or P for next or previous slide. Among the properties that aren't compatible across browsers are fromElement, which is IE, and relatedTarget, which is equivalent for Netscape. These properties capture the object the mouse moved away from with mouse events. Comparable properties are toElement and currentTarget (IE and Netscape, respectively)noting the element to which the mouse moved. These sets of properties are useful when doing drag and drop. The srcElement and target are properties that represent the object receiving the event. One way to grab this information is to use the same cross-browser trick shown in Example 6-3: var theSrc = theEvent.target ? theEvent.target : theEvent.srcElement; alert(theSrc); Another pair of properties that aren't cross-browser compatible are cancelBubble and stopPropagation. These have to do with event bubbling, which is covered next. 6.1.2. Event BubblingWhen you click a web page, you're not just clicking the document, you're also clicking on a link, or perhaps a DIV element, and so on. In most cases, you don't have to worry about it because you've most likely set an event handler for only one element. What happens, though, if you set the same event handler for multiple elements? In what order do they fire, and how do you keep the event from triggering the event handler if you want only one element to be impacted at a time? In Example 6-4, the web page has two DIV elements, one inside the other. They and the document object are all assigned event-handler functionality for the mousedown event. Example 6-4. Bubble-up behavior with multiple elements
Figure 6-1 demonstrates what can happen with a stack of elementspage objects who share the same location in the page, differing in their order from top to bottom. In the figure, the top DIV element is clicked by the mouse, but the DIV element it's contained in, as well as the document object, also receive the event, and the event handler's triggered. Figure 6-1. Event bubbling With Firefox, the event handlers for the elements fire from top to bottom; in IE, it's the reverse. Even in this, we're dealing with differences. The concept of events and their propagation between elements in a stack is usually known as event bubbling, though Netscape once designed around the concept of event capturing. Back in bad olden times, Netscape and IE had a worlds-apart view of events and objects and their relationship to one another. Netscape designed Navigator 4.x so that events moved down the stack of elements from top to bottom. The event would fire with each element, unless you captured the event to prevent it from continuing. Netscape provided a function, captureEvent, just for this purpose. Microsoft, though, designed IE to follow a bubble-up model. This means that an event fell through the stack of elements to the bottom-most element that had a handler, and then would bubble up from there. Of course, you may not want an event to trigger other event handlers if a certain condition is met. You can then cancel the event propagation, whether it's on its way down, or on its way bubbling up. Unfortunately, canceling an event in this older event model is also cross-browser dependent. To cancel an event within IE, use the IE event's cancelBubble property; for the Netscape/Mozilla model, you use the event's stopPropagation method. The way to determine which to use is to test for the existence of the stopPropagation method and, based on the result, use one or the other. In Example 6-4, you can add a stopEvent function to manage this, passing the cross-browser-compatible event object: function stopEvent(evnt) { if (evnt.stopPropagation) { evnt.stopPropagation( ); } else { evnt.cancelBubble = true; } }Calling this function at the end of the mouseDown event prevents document.onmousedown from being triggered in the Netscape/Mozilla path and within the Microsoft event model. Note that I test whether the stopPropagation function exists rather than cancelBubble because cancelBubble will return false if the value is false or if the property doesn't exist. We've been accessing the event object, but what about the target of the eventhow can we access this consistently? The object of interest here is this. 6.1.3. Event Handlers and thisWithin an event-handler function or method on an object, one way to get code to access the properties of the containing element is to use this. For instance, in the following event handler function for the window onload event, this is used to access the function's object's property status: window.onload=setupEvents; function setupEvents( ) { alert(this.status); } The approach is a good shortcut to test form values, without having to follow the path of document to form name, to field name, and so on. In Example 6-5, the blur event for a form element is assigned to an onblur event handler, which then uses this to access the form element's value property. Example 6-5. Use of this with event handlers
When the input field is clicked, a pop-up window opens and displays its value. Chapter 7 provides more demonstrations of this element/event integrations. This older event model described is still supported, more or less, with modern browsers. Though I don't cover the older Navigator 4.x or IE 4.x and 5.x browsers in the book, their legacy lives on in inline event handlers. I've been splitting the two event models into Netscape/Mozilla and Microsoft/IE, but the actuality is that the Netscape/Mozilla path is also the one of open specification, which makes it the W3C path. Referring to the path as "Netscape" disregards that this event model is supported in browsers such as Apple's Safari and Opera. As regards events, the W3C eventually came out more or less on the side of Microsoft and event bubbling, with a nod to event capturing. Within the W3C specifications and most modern browsers, the event proceeds down the stack of elements, each captured in turn. It then bubbles back up, firing the event handlers as it goes. This new event model is covered in the next section.
A major difference between the DOM 2 Event model and the earlier versions is that it isn't dependent on a specific event-handler property, which means you can register multiple event-handler functions for any one event on any one object. Instead of the event-handler property, each object has three methods: addEventListener, removeEventListener, and dispatchEvent. The first is to add an event listener, the second to remove an existing listener, and the third to dispatch a new event. The syntax of the addEventListener is: object.addEventListener('event',eventFunction,boolean);The event, such as click or load, is the first parameter; the handler function is the second; and whether the event is treated as a cascade-down or bubble-up event is the third. If the third parameter is false, the event listener is treated as bubble up; otherwise, true turns the event listener into a cascade-down listener. In Example 6-6, a form with one element, a submit button, is added to the page, and the click event is captured for both, as well as document. Handlers are attached to the event for both the cascade-down (writeY) and bubble-up (writeX) propagation. In the handler functions, the event object is accessed, and two properties, target and currentTarget, are printed out. We'll get to the new event properties in a moment. Example 6-6. Trapping events with DOM Level 2 event handlers
Clicking the button causes six pop-up windows. In Firefox, these are the values that print, in order: Capturing [object HTMLInputElement] [object HTMLDocument] Capturing [object HTMLInputElement] [object HTMLFormElement] Capturing [object HTMLInputElement] [object HTMLInputElement] Bubbling: [object HTMLInputElement] [object HTMLInputElement] Bubbling: [object HTMLInputElement] [object HTMLFormElement] Bubbling: [object HTMLInputElement] [object HTMLDocument] What's happened is that the capturing event is processed first, and the handlers for the document, the form, and then the element itself are processed in order. This makes sense, when you consider that cascade means that the lowest element in the stack of elements is processed first, then the next highest, and so on until the target element is reached. This sequence is reflected in the currentTarget property. However, the original element that received the event is always maintained in the target property. Next, the bubbling phase occurs, and the order of process this time is from form element, to form, to documentbottom up. Again, the event's currentTarget reflects the event propagation, while the target reflects the actual element that received the event. What happens if you want to stop the propagation? Use the removeEventListener. Example 6-6 is modified to add the following function: function stopNow( ) { document.removeEventListener('click',writeX,true); document.forms[0].removeEventListener('click',writeY,true); document.forms[0].elements[0].removeEventListener('click',writeY,true); }For the sake of demonstration, the following hypertext link is added with an inline event handler below the form: <p><a href="" onclick="stopNow( ); return false">Stop Now</a></p> When you click this link, along with triggering the document's event handler, the capturing event handlers assigned to the click event for the form, form input, and document are all removed. When you click the button now, only the bubble-up event handlers are processed. The concept and execution of addEventListener and removeEventListener are terrific, except for one thing: Microsoft supports only its own event-handler model. Even within the new IE7, the company supports only what it has created itself. At the Microsoft IE weblog, IEBlog, author Dave Massy wrote the following about AddEventListener:
Since it took several years for Microsoft to release IE7, it's unlikely that a Microsoft product will support the W3C event model any time soon, so we'll need to look at a workaround. The comparable IE methods for addEventListener and removeEventListener are attachEvent and detachEvent, respectively. The syntax for attachEvent is: object.attachEvent("eventhandler", function);The syntax for detachEvent is the same as for attachEvent: the first parameter is the event handler, the second the function. Though the ways to attach the events differ, it's relatively easy to compensate for this difference. Example 6-7 provides an example of a cross-browser web page that handles the click event for a specific document element. Example 6-7. Cross-browser event handling
The code tests to see if addEventListener is supported. If it is, it's used to attach the event. If it isn't, attachEvent is used. Contrary to the event handlers in the traditional model, an event object does get passed with the attachEvent as it does with addEventListener. Unfortunately, though, the contextual object, this, is associated with the window object regardless of object and event. With the W3C model, this is associated with the object that received the event. Again, though, testing for window.this, as compared to this, and assigning whichever is found to a variable should manage this difference. Another concern with the Microsoft model is that memory is set aside for each event handler, and if you reload the page, additional memory continues to be set aside for each successive page loadingleading to significant memory usage after a while. To avoid excessive memory use, you can trap the window unload event and detach each event with detachEvent. This kick-starts the memory management system to unload that memory when the page is unloaded. In Example 6-7, the cleanup function is assigned to the window.onunload event handler and manages this activity. As for the event object that gets passed, this isn't the same among event model implementations, either. Differences also exist in properties on the event object and the events supported. The following is a list of properties on the event; whether they are set or not depends on the type of event. Not all browsers support all event properties; where a property is not supported, an undefined value is returned when the property is accessed:
As mentioned, not all browsers support all properties. In particular, Internet Explorer does not support many of these properties. If you try to access those it doesn't support, you'll get an undefined value. For example, accessing currentTarget returns an undefined value. The events discussed earlier in this section are supported in the newer event system, as are additional ones relative to the DOM. These include keypress, click, the mouse events, window loading, and events specific to working with forms and form elements.
6.1.4. Generating EventsEvents usually start when someone accesses the page. Either he pushes a button, clicks a link, makes a selection, etc. There are times, though, when you might want to trigger an event. To trigger an event on a web page or page element, it has to be an event that's associated with the type of element. For instance, you can trigger a click on a form button, but not a form text-input field. In this case, the event is click, and the method called on the object is click: <input type="button" name="someButton" value="Some Button" /> ... document.formname.someButton.click( ); One reason for directly invoking an event is to use the focus event on an input field in order to move the cursor to the field. In Example 6-8, when the page is loaded, the focus is set to the last-name field, rather than the first name, which is the first field. Example 6-8. Using focus to move the cursor to a field
In Chapter 12, we'll use focus and a few other tricks to create a dynamic forms validationmoving the cursor to a field that's invalid and highlighting the errors directly in the page. Two other methods based on events, reset and submit, are used with forms. You can use reset( ) to reset the form contents back to their initial values (as specified with the value attribute). You can also use submit( ) to submit the form for processing. In fact, this is probably one of these most common reasons for triggering an event directly: document.formname.submit( ); Using submit( ) is equivalent to pushing a submit button on the form. More on forms, form elements, and Just-in-Time (JiT) validation using events in Chapter 7. |
EAN: 2147483647
Pages: 151