| home / programming / javascript / professional / chap4 / 3 |
   [previous] [next] |
|
|
Analyzing the Example and its ConventionsIn the example above, the first text field has the event handler embedded in the HTML tag. Any amount of code can go here, but unless the handler is trivial as in the example, usually a function will be called. Notice the this keyword is used. In Chapter 2, it was discussed how this gives access to the current object, or the object in whose scope the script is running. In the example above, the current object is the specific form element the user changed. Also notice the return keyword is used. Unlike JavaScript URLs, JavaScript event handlers are supposed to always return true or false although this is: a) not enforced, b) not always necessary, and c) sometimes doesn't even do anything. Read about event processing further on in the book for the implications of true and false. For now, we just note that it is a good habit to always return true. The last text field has an onChange event handler or trigger, but it's not specified in the <INPUT> tag. At the bottom of the example is a line with the word 'last' in it, which is the name for the third text element as specified in the tag. This line allocates the 'shout' function to the onChange event for that element. From JavaScript, if you want to be portable, you can only assign a whole function to an event, not a scrap of code as for the first function. For Internet Explorer 3.0+ you can use a different syntax: the FOR EVENT= HTML syntax to assign a scrap of code. This is not recommended unless you're sure that Internet Explorer is the only browser your users will use. Finally, you can portably assign an anonymous function if you don't want to declare one, but it's harder to read what's going on. Above the line assigning a handler to the last element is a similar line. This does the same thing, but for the middle HTML form element which has no name in the <INPUT> tag. This is an example of objects and arrays being (nearly) interchangeable in JavaScript. Notice the shout() function declared in the head also uses the this keyword, so there is an expectation that it will be used as a method of an object, which is true. The shout() function also has one argument, obj. This argument is not used in early JavaScript browsers, and in those cases will always be null. In Navigator 4.0, an Event object associated with the event will be passed to the event handler function, containing interesting bits about the event. Internet Explorer 4+ looks at a global variable for event details, not a function argument. Since the shout() function is declared in the <HEAD>, why put the JavaScript event handler assignment script elsewhere in the body? Because the browser works from the top of the HTML document down when displaying it to the user. This means some bits of the document, such as the text elements, appear before others. Before they appear, these elements don't exist, which would make it hard to assign event handlers to them. The assignment has to be done after the elements are created. Assigning handlers inside the element tag is the better method, because this problem is avoided and everything about the tag is in the one place. Here's an example of the page being tested. First, the page itself: 
Secondly, the response from the event handler. 
onError and Event ComplicationsNot all event handlers can be set in HTML tag attributes. The most notable exception is the onError event handler of Netscape 3.0 and 4.0. It can be set in the <IMG> tag using the ONERROR attribute. The event also occurs for windows and frames but there is no tag attribute to use. In those cases it must be set directly from a script. Again, the event model is described later in this chapter. Secondly, Netscape 4.x supplies new event management routines in JavaScript: captureEvents(), releaseEvents(), routeEvent() and handleEvent(). In earlier versions, certain events fired certain event handlers, and that was it. With these new routines, those existing events can move to new places, firing handlers that previously wouldn't have taken part. This is a behavioral change, rather than a new place to put handlers. Thirdly, Internet Explorer 4+ allows potential event handlers to be structured in a hierarchical manner, if the scriptwriter arranges it correctly. Events move up the hierarchy in a manner called event bubbling, starting with the most specific handler possible such as an individual HTML tag, and working up towards more general handlers such as window or document handlers. The event is disposed of when a potential event handler exists to receive the event. The handler is triggered, performs actions, and then may elect to stop the event from bubbling up any further.
|
| home / programming / javascript / professional / chap4 / 3 |
[previous] [next] |
| ||||||||||||||||||||
Revised: March 21, 2001
Created: March 21, 2001
