Introduction to Viewlink
10/23/2013
24 minutes to read
In this article
Viewlink is a feature of element behaviors that enables you to write fully encapsulated Dynamic HTML (DHTML) behaviors and import them as robust custom elements in a Web page. Viewlinked document content, otherwise known as the document fragment, renders and behaves as regular HTML content in the main Web page. Either binary DHTML behaviors or scripted HTML Component (HTC) can be used to implement an element behavior with a viewlink, but this overview focuses primarily on the use of viewlink in scripted HTC files.
In Microsoft Internet Explorer 6, a new section on Themes has been added.
Element behaviors that use viewlink are highly encapsulated, so it is now practical to design and build sophisticated Web applications using a highly modular approach. Encapsulation has proven to be both intuitive and advantageous in other development environments, such as Microsoft Visual C++ and Microsoft Visual Basic, and promises to be equally beneficial for the Web development scenario.
When a viewlink is used, script in the primary document does not affect the rendering of the behavior—unless public methods and properties are added to the component definition to make this possible. A component can be completely encapsulated, such that its functionality, methods, and style sheet properties are completely hidden from the primary document. Conversely, a component can be designed to provide an extensive interface of methods and properties, enabling rich interaction between the primary document and the component. Therefore, the Behavior Component Model in Internet Explorer 5.5 provides a great deal of flexibility for component developers.
There are some important differences between regular element behaviors and those that use a viewlink. A regular element behavior defines a custom element; so when discussing an element behavior that uses a viewlink, the custom element in the primary document is referred to as the master element. This distinction is made because each type of element behavior has a different effect on the primary document tree. The document fragment of a viewlinked element behavior does not appear in the primary document tree, but it is displayed. This is because the document fragment is encapsulated by the viewlink, whereas, the document fragment from a regular element behavior is appended directly to the custom element. These distinctions mean that a somewhat different syntax is used when scripting the Document Object Model (DOM) for each type of behavior.
One benefit of using DHTML behaviors written with HTC files is that they do not require installation on the client machine, whereas binary DHTML behaviors generally do. HTC files are downloaded and rendered automatically as a part of the main Web page, so the result is a smoother browsing experience. Scripted components in Internet Explorer 5.5 can be very powerful, in fact, they are very nearly as capable as binary DHTML behaviors—yet they are much easier to develop.
This article explains how to use the viewlink feature and covers the primary benefits that can be realized from using it in conjunction with element behaviors. A variety of samples are also included to illustrate how to write your own viewlinked element behaviors.
The following topics are discussed in this document.
Prerequisites
Terminology
Benefits
Calendar Sample
Creating a Viewlink
Creating an Element Behavior
Defining a Viewlink
Importing the HTC file
Example
Canceling a Viewlink
CSS Inheritance
Inline vs. Block Elements
Event Routing
Special Case Events
Mouse Events
Focus and Blur Events
Events Not Fired Automatically
Tabbing
Themes
Nesting Viewlinks
Security
Related Topics
Prerequisites
To maximize the benefit of reading this article, you should be familiar with DHTML behaviors and the concepts behind writing behaviors with HTC files.
Readers who are new to DHTML behaviors are encouraged to review the following articles: HTC Reference, Introduction to DHTML Behaviors, and About Element Behaviors.
Because viewlink is a special feature of element behaviors that encapsulates the document fragment, the About Element Behaviors overview is particularly relevant for anyone who wishes to use viewlink.
Terminology
This section defines the terminology used to describe the viewlink feature.
custom element
A user-defined element that implements an element behavior, also known as a custom tag.
document fragment
One or more HTML elements that exist independent of the main body of content in the primary document. The viewlink feature, or other scripting methods such as appendChild, can be used to insert a document fragment into a primary document and render it.
element behavior
A new type of DHTML behavior available in Internet Explorer 5.5 that allows a custom element to be completely bound to an HTC file. A custom element that implements an element behavior can be used like a standard HTML element in a Web page. The functionality of the element behavior is never removed from the element.
master element
A custom element that implements an element behavior with a viewlink.
primary document
A Web page, using element behaviors, that is being viewed in the browser.
namespace
A collection of names that can be used by custom elements or attributes. A namespace is used to ensure that elements are uniquely qualified. See XML Tutorial: Using Namespaces for more information.
There are several differences between the techniques used to create binary DHTML behaviors and those that use HTC files, but their discussion is outside the scope of this overview. Therefore, in this article, the terms element behaviors and viewlink refer to DHTML behaviors written with HTC files, unless otherwise stated. For more information on binary behaviors, see the article Implementing Binary DHTML Behaviors.
Benefits
The element behavior and viewlink capabilities, which are introduced in Internet Explorer 5.5, empower you to define robust custom elements. The Internet Explorer 5.5 platform provides a solid foundation on which to build fully encapsulated DHTML components, which can be used to extend the basic feature set provided by regular HTML elements. In fact, the new DHTML behavior capabilities of Internet Explorer 5.5 are all that is necessary to build an enormous variety of sophisticated controls and components. So Internet Explorer 5.5 encourages the development of reusable components, and this is particularly appealing because you can write them using scripted HTC files.
The following diagram illustrates the difference between an element behavior with and without viewlink. On the left, a simple document tree structure is shown where an element behavior has been implemented. The custom element, shown in yellow, also appends the document fragment to the primary document. The result is a document tree that consists of the primary document and the document fragment. On the right, an element behavior with viewlink has been implemented. The result is clearly much simpler. Only the master element appears in the primary document tree, by virtue of the encapsulation of the document fragment.
A useful feature of viewlink is that it enables the developer to partition the document tree into multiple document fragments by using nested viewlink components. This introduces interesting possibilities; there are many scenarios where it can be highly desirable or efficient to abstract content and script into multiple layers. The following Calendar sample illustrates one possible use of nested viewlink components; it also illustrates some other interesting benefits of viewlink.
Many problems encountered with the development of DHTML behaviors are avoided when an element behavior when a viewlink is used. Styles in the primary document tree are not inherited by the viewlink component unless the component author permits it by design. Unexpected formatting of the component content can be avoided completely by defining styles in the HTC file, which take precedence over styles set in the primary document. You also have the option to turn off style inheritance completely; the technique is explained in the CSS Inheritance section.
Calendar Sample
This sample uses a Calendar component implemented using two different variations: the first is an element behavior and the second is an element behavior with a viewlink. Although very similar in appearance and function, the Calendars illustrate some interesting differences that result from Viewlinking an element behavior.
Each component has a button to display the HTML document tree, highlighting the difference in primary document structure that results from each variation. In the element behavior version, the primary document tree structure is considerably more complex than the viewlink version. The primary document for the element behavior is filled with numerous elements branching off from the custom element, whereas the viewlink version shows how the contents of the document fragment have been encapsulated in the HTC file. The sample also illustrates the difference in Cascading Style Sheets (CSS) inheritance for each variation. A button applies a background style to the table elements in the primary document. When the style is applied, elements inside the element behavior inherit the updated style property. This result could be undesirable, depending on the requirements for the component. For the viewlink version of the Calendar, applying the style in the primary document has no effect on the rendering of the Calendar control.
Creating a Viewlink
Before going through the basic steps to create a simple viewlink, it is worth taking a quick look at the defaults object and its properties. This object is fundamental to understanding how element behaviors make use of the viewlink feature. The defaults object has several properties that are used in association with viewlink.
The defaults object is used to set and retrieve the default properties for element behaviors, so it follows that viewLink is one of the properties of this object. A viewlink is established for an element behavior when the viewLink property is set to an object containing document content. The object that is assigned to the viewLink property is the document fragment. By default, an element behavior does not have a viewlink defined, so the initial value of the viewLink property is null.
The PUBLIC:DEFAULTS element is the declarative form of the defaults object. The attributes supported by the PUBLIC:DEFAULTS element correspond to the properties collection of the defaults; so either script or declarations can be used to set the defaults object properties. The PUBLIC:DEFAULTS element is used in the component section of an HTC file, where the initial properties of the defaults object can be set.
Three basic steps are required to create and implement an element behavior that uses a viewlink:
Create an element behavior.
Define a viewlink.
Import the HTC file in the primary document.
Each step is described in the following sections.
Creating an Element Behavior
Viewlink is a feature of element behaviors; therefore, the process of writing element behaviors with or without a viewlink is quite similar. The process of creating an element behavior is covered in detail in the About Element Behaviors overview.
Defining a Viewlink
A viewlink can be defined using script or by inserting the appropriate declaration in the component section of the HTC file.
To set up a viewlink between a primary document and a document fragment using script, the following statement can be used. This statement is placed within script located in the HTC file, ideally the script block should be placed after the PUBLIC:COMPONENT element.
defaults.viewLink=document;
A viewlink can also be established using a declaration in the component definition. The following example automatically links the root element of the document fragment in the HTC file to the master element in the primary document.
An HTC file is essentially a regular HTML document, so it can contain a head and body element and other standard HTML elements; but it is only necessary to include the elements that define the behavior and the document content. For element behaviors that use viewlink, the HTC file contains two main sections. The first section is the component definition, which is the PUBLIC:COMPONENT element and the elements contained within it. The PUBLIC:COMPONENT element contains declarations that define the interface for the behavior in terms of its methods, properties, and event handling. It is recommended that script blocks not be inserted in this section. The second section is the document fragment, which is contained inside the body element. This includes any static HTML that is to be displayed in the primary document.
Here is a simple HTC file that uses a declaration to set the viewlink in the PUBLIC:DEFAULTS element.
Some day this will be a toolbar button.
Importing the HTC file
This section explains how to import an HTC file as an implementation of an element behavior that uses viewlink. Importing a master element into the primary document is a trivial step, but the master element itself deserves some commentary. The name of the master element is declared in the HTC file using the tagName attribute in the PUBLIC:COMPONENT element, as shown in the previous sample code example. The master element takes the namespace as its prefix, followed by a colon (:), and then the tag name. As many master elements as necessary can be included in the primary document.
A viewlink displays the document fragment in the primary document at the location of the master element. The contents of the master element are not rendered in the primary document unless the behavior fails to initialize. If the component initialization does fail, then the contents of the master element are rendered instead of the document fragment. The contents of the master element are available in script through the innerHTML and innerText properties.
Example
The following HTC file defines a custom element named TOOLBAR_BUTTON. Moving the mouse pointer over the button causes it to have a 3-D effect. This effect goes away as soon as the mouse pointer is moved off the button.
In the following example, the component waits for the oncontentready to initialize the viewlink. The PUBLIC:ATTACH element is used to map the fnInit function as the handler for the oncontentready event. Another way to attach functions as event handlers is to use the attachEvent method in script.
.clsButton { background-color:#D6D3CE;
border:solid 1px;
border-color:#D6D3CE;
}
// Entry point
function fnInit()
{
var oButton = document.body;
oButton.className = "clsButton";
oButton.innerHTML = " " + element.innerHTML + " ";
defaults.viewLink = document;
}
// Mouse handler functions
function fnMouseOver()
{
var oButton = document.body;
oButton.style.borderColor = "ThreeDHighlight " +
"ThreeDDarkShadow " +
"ThreeDDarkShadow " +
"ThreeDHighlight";
oButton.style.cursor = "hand";
}
function fnMouseOut()
{
var oButton = document.body;
oButton.style.borderColor = "#D6D3CE";
oButton.style.cursor = "default";
}
function fnOnMouseDown()
{
var oButton = document.body;
oButton.style.borderColor = "ThreeDDarkShadow " +
"ThreeDHighlight " +
"ThreeDHighlight " +
"ThreeDDarkShadow";
}
function fnOnMouseUp()
{
var oButton = document.body;
oButton.style.borderColor = "ThreeDHighlight " +
"ThreeDDarkShadow " +
"ThreeDDarkShadow " +
"ThreeDHighlight";
}
οnmοuseοut="fnMouseOut()"
οnmοusedοwn="fnOnMouseDown()"
οnmοuseup="fnOnMouseUp()">
The next file is the primary document, which uses the toolbar button implemented in the previous file.
Toolbar Button Demo.clsButton { font-family:Arial,Helvetia,sans serif;
font-size:12;
}
function fnClick()
{
alert("You clicked: " + window.event.srcElement.innerText);
}
New
Open
Save
Save As...
Canceling a Viewlink
When a viewlink is canceled, the HTC file content dynamically disappears from the primary document. As the viewlink detaches from the primary document, the page dynamically updates. If the master element has any content, it replaces the viewlink content when the document rendering is updated. Viewlink components can be canceled by using a declaration or by using script. The following sample shows how this is done using script.
defaults.viewLink=null;
CSS Inheritance
Viewlink provides the capability to encapsulate the CSS style settings in the document fragment. Generally, the CSS properties in the primary document and the document fragment are independent of one another, but it is also possible to control the inheritance of style settings from the primary document to the document fragment.
The default setting for a viewlink is that CSS properties set at the master element are inherited by elements in the document fragment. The component author can override any CSS styles in the primary document by setting the corresponding styles explicitly in the HTC file; styles in the component file take precedence over any styles applied to the master element in the primary document. The About Viewlink CSS Inheritance page provides detailed information on the inheritance of specific CSS properties.
CSS inheritance is controlled by the Boolean viewInheritStyle property. If viewInheritStyle is set to TRUE, then inheritable CSS styles set in the primary document are inherited by the corresponding elements in the document fragment.
Using the toolbar button sample from the previous section, the font of the buttons can be changed to bold by applying the appropriate CSS style at the master element, since this is an inheritable style. For example:
New
The text color of the buttons cannot be changed by applying the color CSS style. This is because the viewlink component specifically sets color in the style block of the HTC file, overriding the style set in the primary document.
.clsButton { color:#0000FF;
background-color:#D6D3CE;
border:solid 1px;
border-color:#D6D3CE;
}
Inline vs. Block Elements
By default, element behaviors render as inline elements in the primary document. Even block elements that are imported with the behavior render as inline elements. If you want the viewlink to render as a block element, you must set the element's display style to "block".
In this sample HTC file, the document fragment contains a DIV element—a block element. However, when the primary document renders, the master element and its DIV child render as inline elements. Script in the sample sets the display style of the master element to "block" when the element is clicked. The child element inherits the block style.
element.style.backgroundColor = "yellow";
function makeBlock() {
//Make the element a block element by setting the display style to 'block.'
element.style.display = "block";
animalDiv.innerHTML = "Viewlink behavior: The owl and the pussycat.";
}
*Viewlink behavior: Click me if you dare.
This sample primary document contains the document fragment.
Containing page: The tortoise and the hare.
*Click the viewlink behavior to change it into a block element.
Event Routing
This section describes how events are handled with respect to viewlink components and the primary document. Events can be fired from the document fragment to the primary document and vice versa. It is important to understand that some events are not fired to viewlink components at all. There are also certain events that require special consideration.
In general, bubbling events are fired across viewlink components, whereas non-bubbling events are not. Most user events, such as those involving the mouse and keyboard, are fired across. The most commonly used events with viewlink components are fired on the master element.
If an onclick event is fired on a div element in an HTC file, it bubbles up the tree of the HTC file until it reaches the root element. Without event firing, this onclick event remains local to the HTC and is not seen in the primary document. However, Internet Explorer 5.5 automatically fires events to the primary document. Furthermore, the event is fired on the master element and continues to bubble up the primary document tree. In the primary document, the srcElement property for the event would appear to be the master element.
It is also worth noting that standard DHTML events can be attached to elements in the document fragment, but events that are specific to HTC components, such as oncontentready, cannot. Binding to HTC specific events must be done using the PUBLIC:ATTACH element.
For a comprehensive listing of events and how they are handled by viewlink components, see the About Viewlink Event Routing page. The following sections describe the main types of events and how they operate with viewlink.
Special Case Events
When events are fired in the primary document, the master element of a viewlink behaves just like all other tags in the primary document. For example, if a user moves the mouse pointer over a viewlink component, an onmouseover event is fired on the master element. When the user moves the mouse pointer out of the component, an onmouseout event is fired on the master element. However, when the user moves the mouse pointer over elements within the viewlink component, the onmouseover and onmouseout events are not fired back to the primary document. Special case events have been created to indicate when mouse and focus events are fired back to the master element.
Mouse Events
The onmouseover and onmouseout events are fired on the master element only when the onmouseenter and onmouseleave elements are fired, respectively, on the top-most element in the HTC tree.
The onmouseenter and onmouseleave events do not bubble, nor can they be canceled. The onmouseenter event fires when the mouse pointer enters an element, and the onmouseleave event fires when the pointer leaves the element. The key is that these events do not bubble. Therefore, the only occurrences of these events in the HTC that are fired on the primary document are those that occur on the root element of the HTC tree.
For example, if onmouseenter fires on the root element, both the onmouseenter and onmouseover events fire on the master element. The same action occurs for an onmouseleave event and a corresponding onmouseout event.
As a result, when the mouse pointer moves over a master element in the primary document, one onmouseover event fires. When the mouse pointer is moved out of the master element, one onmouseout event fires. If the mouse pointer is moved in or out of elements within the viewlink, the corresponding onmouseover and onmouseout events are not fired on the master element; they remain local to the HTC file.
Focus and Blur Events
The relationship described in the preceding mouse events section also holds for onactivate and onfocus, as well as ondeactivate and onblur.
For example, if the focus changes between two elements inside a viewlink document fragment, multiple focus/blur events do not fire on the master element; this is because the master element does not lose focus in the primary document while the events take place. Consequently, these focus events are treated in exactly the same way as the mouse events. The onactivate and ondeactivate events cannot be canceled. When the onactivate and ondeactivate events are fired on the root element of the HTC tree, the onfocus and onblur events, respectively, are fired on the master element in the primary document.
The onbeforedeactivate event does not bubble but can be canceled. The same scenario applies to this event as discussed previously. For example, if a user is tabbing between two elements in a component, multiple events are not fired on the master element. As a result, only occurrences of these events on the root element of the HTC tree are fired on the master element. In addition, because these events can be canceled, focus on the master element can be canceled.
Events Not Fired Automatically
Events that are not fired automatically from the document fragment to the master element can still be fired through script. The following example shows how to manually fire an event from an HTC file to a primary document.
Move the mouse over this text.
Tabbing
The viewlink feature is available due to the new Behavior Component Model in Internet Explorer 5.5, one that allows a custom tag to render the content from a document fragment containing multiple elements. Therefore, additional considerations arise with respect to controlling the tabbing sequence in viewlink documents.
By default, the elements in a viewlink document fragment do not participate in the tab order of the primary document, but by setting the appropriate properties, it is possible to make viewlink content participate in the tab order.
This section describes how tabbing between the primary document and the document fragment can be controlled. Three properties are available to control the tabbing sequence:
Before explaining the specific details of tabbing with viewlink components, it is useful to consider the basic rules for tabbing between elements in a normal Web page:
All objects with a tabIndex greater than 0 are selected in increasing tabIndex order, or all objects with duplicate tabIndex values are selected in source order.
All objects with a tabIndex equal to 0, or without tabIndex set, are selected next, in source order.
Elements with a negative tabIndex are omitted from the tabbing order.
Within the viewlink component, tabbing is encapsulated and independent from the tabbing sequence in the primary document. The component author has control over tabbing within the document fragment and the page author controls tabbing in the primary document. Elements in the document fragment follow their own tabbing sequence, which is defined by the tabIndex property. If tabIndex is set to a value greater than zero on the master element, the component also participates in the tab sequence of the primary document.
During tabbing between objects in the primary document, the master element behaves according to the basic tabbing rules listed above, just like any other element in the primary document. Once the master element receives the focus, tabbing control is handed over to the viewlink component. Once tabbing reaches the viewlink component, elements within the viewlink receive focus according to the tabbing sequence and follow the basic tabbing rules. Once tabbing in the document fragment has cycled through the all elements, in the specified tab order, it returns to the primary document and tabs to the element following the master element in the tabbing sequence, if there is one. If there is no element in the tabbing sequence following the master element, then tabbing begins another cycle through the primary document.
The master element has an attribute called tabStop, which specifies the initial tabstate of the tag; this attribute is also a property of the defaults. tabStop controls whether a component participates in tabbing; its default setting is FALSE. It is important to note that the tabStop setting is overridden by the tabIndex property. Setting tabIndex to a negative value on the master element prevents the component from participating in tabbing, even if the tabStop attribute has a positive value in the HTC component.
If tabIndex is not set on the master element and tabStop is not set in the HTC, the viewlink component does not participate in tabbing. Therefore, the viewlink document fragment does not participate in the tab order by default.
The viewMasterTab property sets or retrieves whether the master element of a viewlink is included in the tab sequence of the primary document. By default, the master element participates in the tab sequence of the primary document, even if there are no tab stops defined within the viewlink.
Themes
Internet Explorer 6 and later. A theme that is applied to the primary document may not also be applied to the viewlink component. To ensure that it is, you must set the HTTP-EQUIV and the CONTENT attributes of the META element to MSTHEMECOMPATIBLE and yes, respectively. Place the META element within the PUBLIC:COMPONENT portion of the HTC file. See HTTP Response Headers reference page for a list of values for the HTTP-EQUIV attribute.
Nesting Viewlinks
An HTC file can be imported into another HTC file, such that the components are nested. Nesting can be done with normal element behaviors as well as those that have a viewlink. Consider the case of a calendar behavior that uses viewlink. Each day in the calendar can be represented by another viewlink, which displays a pop-up window containing the day's appointments. The HTC file for the CALENDAR tag would have an IMPORT processing instruction, which imports the implementation of the DAY tag.
Here is the primary document for this scenario.
Calendar ExampleClick a day in the calendar...
Here is the HTC file that implements the CALENDAR tag. Note that the calendar HTC file contains the processing instruction to import a namespace for the day.htc file; it also includes custom elements for each day in the Calendar in the document fragment.
function fnInit()
{
defaults.viewLink = document;
}
TD { text-align:center;
border:solid 1px;
cell-padding:2;
cell-spacing:2;
width:50;
height:50;
}
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
Finally, here is the HTC, which contains the implementation of the DAY tag.
.clsDay { width:50;
height:50;
background-color:lightyellow;
align:center;
}
function fnInit()
{
document.body.innerText = element.value;
document.body.className = "clsDay";
defaults.viewLink = document;
}
function fnShowAppts()
{
alert("Show appointments for day " + element.value + "!");
}
扫一扫
2258
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
