Share this page
Creating a Behavior script component is similar to creating any other kind of script component, except that you are linking Microsoft® Internet Explorer events to script that is run in response to those events.
This topic is divided into the following sections:
Creating a Behavior Script Component File
A Behavior script component includes an <implements> element that specifies the Behavior interface handler. Within the <implements> element, you use:
<attach>elements to bind events from the containing document to functions created in a separate <script> element in the script component.
<layout>elements to define HTML text to be inserted into the containing document.
<event>elements to define custom events that will be fired by the script component.
Behavior script components can also include custom properties and methods that extend those already available for the element in the containing document. For details, see Exposing Properties and Methods in Behavior Script Components.
The following example shows a Behavior script component that changes the color of an element in the containing page whenever the mouse is passed over the element. To do this, the sample binds the DHTML onmouseover and onmouseout events to functions in the script component that set the element's DHTML style attribute. The sample also sets the document's link color when the document is initialized by binding to the DHTML window object's onload event.
In addition to binding events to script, the script component also inserts text into any <H1> elements in the containing document that are linked to this script component. Finally, it exposes and fires an event called onchange, which extends the DHTML window object's event object with a custom property called newvalue.
 Note |
|---|
A CDATA section is required to make the script in the <script> element opaque. For details, see Script Component Files and XML Conformance. |
 Copy Code | |
|---|---|
<?XML version="1.0"?>
<component>
<implements type="Behavior">
<comment>The following will cause the do_nmousedown and
do_mouseout functions to be called when the mouse is
passed over the element in the containing document.</comment>
<attach event="onmouseover" handler="do_onmouseover"/>
<attach event="onmouseout" handler="do_onmouseout"/>
<comment> This will call the init function when the onload
event of window is fired.</comment>
<attach for="window" event="onload" handler="docinit"/>
<comment>The following defines HTML text that will appear in
the containing document.</comment>
<layout>
<h1>This is the HTML to show in the element</h1>
</layout>
<comment>The following defines a custom event that is fired
from within the script component by the fireEvent method.</comment>
<public>
<event name="onchange"/>
</public>
</implements>
<script language="JScript">
<![CDATA[
var normalColor, normalSpacing;
function do_onmouseover(){
// Save original values.
normalColor = style.color;
normalSpacing= style.letterSpacing;
style.color = "red";
style.letterSpacing = 2;
oEvent = createEventObject();
oEvent.newcolor = "red";
fireEvent("onchange",oEvent);
}
function do_onmouseout(){
// Reset to original values.
style.color = normalColor;
style.letterSpacing = normalSpacing;
}
function docinit(){
document.linkColor = "red";
}
]]>
</script>
</component> | |
There are a few things to point out in the preceding code:
From a script component procedure, the implied this pointer in an event handler refers to the containing function, not to the element on which the event is being fired.
Just as in an HTML page, it is possible to place inline script within a <script> in a script component. In this instance, the global variables normalColor and normalSpacing are defined in inline script.
Note Inline script is executed even before the behavior is applied to the element, which limits what statements can be executed in inline script. For example, if the same behavior in the example exposed a property called hiliteColor, the inline script could refer to hiliteColor directly (in other words, it resolves against the script component's namespace). It is illegal, however, to refer to hiliteColor as Behavior.element.hiliteColor from an inline script, because at that point, the behavior has not yet been applied to the element. For more information, see Scope Rules and Timing Considerations later in this topic.
Behavior-Related Enhancements to the DHTML Object Model
The following enhancements were made to the DHTML object model for Microsoft® Internet Explorer 5 in order to add support for behaviors.
The cascading style sheet (CSS) behavior attribute specifies the location of the behavior.
The DHTML attachEvent and detachEvent methods enable a Behavior script component to receive event notifications from the containing page, by specifying a function that gets called whenever the event fires on the object.
The DHTML uniqueID property enables a behavior script component to assign an ID to the element. This can be useful in cases where a script component injects code into the containing page and needs to specify the ID of the element to which the behavior is being applied.
Getting Event Parameters in the Script Component
In DHTML, the DHTML event object provides information about the event. Although in DHTML the event object is accessible to event handlers through the DHTML window object, in a behavior script component the event object is passed in as a parameter to the event handler.
The following code from a hypothetical calculator script component demonstrates keyboard and mouse events bound to a script component function called doCalc. The doCalc function uses the event object to get information about the conditions under which the event was fired.
| Note |
|---|
A CDATA section is required to make the script in the <script> element opaque. For details, see Script Component Files and XML Conformance. |
| Copy Code | |
|---|---|
<implements type="Behavior">
<attach event="onclick" handler="doCalc"/>
<attach event="onkeydown" handler="doCalc"/>
</implements>
<script language="jscript">
<![CDATA[
function doCalc(oEventParam){
oElement = oEventParam.srcElement;
if(oEventParam.type == "keydown"){
sVal = KeyCodeToChar(oEventParam.keyCode);
}
else{
if (oEventParam.srcElement.type != "button"){
return;}
sVal = stripBlanks(oEventParam.srcElement.value);
}
}
// other script here
]]>
</script> | |
Scope Rules
When working with script components, you actually work with three namespaces: the behavior, the element, and the containing document. Scope rules define the order in which name conflicts are resolved in a behavior script component. A name will be resolved in this order:
The name is resolved to one defined by the behavior anywhere in the script component, whether a variable, a behavior-defined property, a method, or an event.
If the name is not resolved successfully, it is resolved to a property, method, or event that applies to the element.
Finally, the name is resolved to the name of a property, method, or event that applies to the window object in the containing page.
In the following example, note how the names have been resolved, using the scope rules defined above:
normalColor Resolves to the variable defined by the behavior at the top of the script.
style Resolves to the style property of the element in the containing document.
Copy Code<implements type="Behavior"> <attach event="onmouseover" handler="do_onmouseover"/> <attach event="onmouseout "handler="do_onmouseout"/> </implements> <script language="JScript"> <![CDATA[ var normalColor, normalSpacing; function event_onmouseover() { // Save original values. normalColor = style.color; normalSpacing = style.letterSpacing; style.color = "red"; style.letterSpacing = 2; } function event_onmouseout() { // Reset to original values. style.color = normalColor; style.letterSpacing = normalSpacing; } ]]> </script>
Timing Considerations
When creating behaviors, it is important to know when the behavior is applied to the element. Until the behavior has been applied, scripts cannot have access to the values of behavior-defined properties that might be set in the document.
Because the behavior is encapsulated in a separate file from the HTML document, it is downloaded separately from the rest of the document. As the document and behavior are parsed and loaded, the behavior receives notifications of progress through the function specified with the attachNotification method. Currently, the behavior is notified with a "contentChange" or a "documentReady" notification. The "contentChange" notification is sent when the content of the element to which the behavior has been attached has been parsed, and any time thereafter that the content of the element is changed. The "documentReady" notification is sent when the document has been downloaded and parsed.
Because inline script in the script component file is executed as soon as the behavior is instantiated, the values of behavior-defined attributes and properties that are being set in the document may not be accessible from an inline script. However, these properties will be available as soon as the first "contentChange" notification is sent.
See Also
