 | ||||||
| ||||||
To display the data provided by a data source object (DSO), the author binds elements on an HTML page to the DSO. Using the data binding extensions or the corresponding data binding properties makes it easy. This section shows how to bind an element to data, the elements that support data binding, and the capabilities of those elements. Capabilities include support for updating the data to which an element is bound and the format in which the data is displayed—HTML or plain text.
Bindable HTML elements fall into two categories—single-valued and tabular consumers. Single-valued consumers bind to a single field of the current record provided by a DSO. Tabular consumers bind to an entire data set and use their contained elements as a template to repeat the data. In Internet Explorer 4.0, the TABLE element is an example of a tabular data consumer, and the procedure for binding it to data is described below.
The procedure for binding a single-valued element to data is the same regardless of the element. Elements can be bound to data at design time using the DATASRC and DATAFLD attributes or at run time using the dataSrc and dataFld properties exposed by the corresponding objects in the DHTML Object Model.
To specify a complete binding to a field in a data set, data-consuming elements use the DATASRC and DATAFLD attributes. Given a text box, for example, a page author can bind that element to data as follows:
<INPUT TYPE=TEXTBOX DATASRC="#dsoComposers" DATAFLD="compsr_last">
The DATASRC attribute in this example specifies the ID, prefixed by a hash mark (#), of a data source object (DSO) embedded on the page. The hash mark is required. The DATAFLD attribute identifies the field in the data provided by the DSO to which the text box should be bound.
Click the Show Me button to see how it works.
Because the TABLE element is a tabular data consumer, it relies upon the elements that it contains to bind to the individual fields in the data set provided by the DSO. The contained elements serve as a template, and they are repeated once for each record in the data set. The TABLE specifies the DATASRC attribute. The contained elements specify the DATAFLD attribute and inherit the DATASRC from the table. Here's a simple example:
<TABLE DATASRC="#dsoComposer">
<TR><TD><SPAN DATAFLD="compsr_first"></SPAN></TD></TR>
</TABLE>
Click the Show Me button to see how it works.
As with single-valued consumers, a tabular data consumer can be bound to data at run time using the DHTML Object Model. The procedure for accomplishing this is described below.
The previous sections used a TEXTBOX, a SPAN, and a TABLE element to illustrate how to bind single-valued and tabular consumers to the data provided by a DSO. Many other HTML elements can be bound to data. Some of these elements support updating the data to which they are bound. Changes can be persisted to the back-end data set if the DSO supports update. Other elements support rendering of the data as HTML in addition to the plain text default using the DATAFORMATAS attribute.
The following table presents the single-valued HTML elements that support data binding. Additional columns indicate:
Use the drop-down list to filter the elements appropriately.
| Element | Updatable | Renders HTML | Bound Property |
Bindable HTML elements that supply read-only functionality include A (anchor), BUTTON, DIV, IMG (image), FRAME, IFRAME, LABEL, MARQUEE, and SPAN.
Additionally, the BUTTON, DIV, LABEL, MARQUEE, and SPAN elements support the usage of the DATAFORMATAS attribute and the corresponding dataFormatAs property to render the data to which they are bound as plain text (default) and as HTML. The data displayed by the element is automatically updated as the record pointer maintained by the DSO moves or the underlying data to which the element is bound changes. Individual descriptions for these elements follow.
An anchor element applies the data supplied by a DSO to the HREF attribute; thus, the supplied data should represent a URL. An example of a bound anchor is:
<A DATASRC="#dsoLinks" DATAFLD="link_href"><SPAN DATASRC="#dsoLinks"
DATAFLD="link_friendly"></SPAN></A>
A BUTTON element renders the data supplied by a DSO on its face. An example of a bound BUTTON is:
<BUTTON DATASRC="#dsoLinks" DATAFLD="link_friendly"></BUTTON>
Click the Show Me button to see a working example.
A DIV element is useful for displaying a block of text. An example of a bound DIV is:
<DIV DATASRC="#dsoComposer" DATAFLD="compsr_biography"></DIV>
A FRAME element applies the data supplied by a DSO to its HREF attribute; thus, the bound value should represent a URL. So that the binding occurs successfully, the data source object supplying data to a bound frame should be present in the HEAD section of the HTML file containing the FRAMESET. An example of a bound FRAME is:
<HTML>
<HEAD>
<<!-- Add DSO reference here -->
</HEAD>
<FRAMESET>
<FRAME DATASRC="#dsoFAQ" DATAFLD="frame_question" ...>
<FRAME DATASRC="#dsoFAQ" DATAFLD="frame_answer" ...>
</FRAMESET>
</HTML>
The code behind the following Show Me button implements a frame-based FAQ. The first frame displays the question; the second frame displays the answer; the third frame contains navigation buttons. The first and second frames are bound to a two-column table. The first column in the table contains relative paths to pages containing questions. The second column contains relative paths to pages containing the answers. Since the DSO is embedded in the HEAD of the outer page containing the FRAMESET, the code behind the navigation buttons drills out of the page in which it resides using the top object and references the DSO by its ID. The top object returns an object reference to the outermost containing window.
An IFRAME element applies the data supplied by a DSO to its SRC attribute; thus, the data should represent a URL. In contrast to the FRAME case, the DSO can be declared anywhere on the page. An example of a bound IFRAME is:
<IFRAME DATASRC="#DSC1" DATAFLD="iframe_url">
Click the Show Me button to see a working example.
An IMG element applies the data supplied by a DSO to locate, load, and display the image typically pointed to by its SRC attribute. Supplying raw image data through the bound column is not supported.
An example of a bound IMG tag is:
<IMG DATASRC="#tdcImages" DATAFLD="image"></SPAN>
Click the Show Me button to see a working example.
Use a LABEL element to describe another bound element on the page. A label applies the data supplied by a DSO to its caption. An example of a bound LABEL is:
<LABEL FOR=somecontrolid DATASRC="#DSC1" DATAFLD="label_col"></LABEL>
Since a LABEL is associated with other elements indicated by its FOR attribute, using a bound LABEL within a repeated table can yield unexpected results. If the FOR attribute references another element within the repeated table, the LABEL tag will not be associated with the elements, since there will be multiple elements with the same ID/NAME as a result of the repetition.
A MARQUEE element uses its bound data to replace the text that appears between its opening and closing tags.
An example of a bound MARQUEE is:
<MARQUEE DATASRC="#dsoComposer" DATAFLD="bio" DATAFORMATAS="HTML"></MARQUEE>
Click the Show Me button to see a working example.
Like a DIV, a SPAN is a read-only data consumer. Use a SPAN to display inline text or limited HTML text. If the SPAN is used to display HTML text, that text should not include any HTML block elements. When the current record or the underlying value in the bound column provided by the DSO changes, the SPAN reflects the change. An example of a bound SPAN is:
<SPAN DATASRC="#dsoComposer" DATAFLD="compsr_last"></SPAN>
Click the Show Me button to see a working example.
The INPUT (with the exception of the button type), SELECT, TEXTAREA, OBJECT, and APPLET elements support updating the data to which they are bound if the underlying DSO supports update functionality. Descriptions of these individual elements follow.
The INPUT element represents a set of HTML intrinsic controls. Each of the types that support data binding (CHECKBOX, HIDDEN, PASSWORD, RADIO, and TEXT) is detailed in the following sections.
CHECKBOX
Although check boxes allow a value attribute that is used when submitting an HTML form on a page, IE4/MSHTML uses check boxes as simple Boolean selections. Check boxes generate the Boolean values TRUE or FALSE depending on whether they are checked or not. The binding agent coerces the values to and from the underlying data set. The following coercions are supported based on the type of the bound column.
The following table describes the values that a bound check box expects a DSO to supply for various data types.
Data type Expected True value Expected False value String "True" | "1" | <non-empty string> "False" | "0" | <zero-length string> Integer non-zero 0 Float non-zero 0 Date invalid invalid Currency non-zero 0 An example of a bound check box is as follows:
<INPUT TYPE=CHECKBOX DATASRC="#dsoSurvey" DATAFLD="us_resident"> U.S. ResidentClick the Show Me button to see a working example.
This feature requires Internet Explorer 4.0 or later. Click the icon below to install the latest version. Then reload this page to view the sample.HIDDEN
The HIDDEN type is used to store information in the page that isn't displayed to the user. The element is populated with data from the current record, but it cannot be modified.
An example of a bound hidden field is:
<INPUT TYPE="HIDDEN" DATASRC="#DSC1" DATAFLD="key">PASSWORD
The PASSWORD type is basically the same as the TEXT type except that the bound text is not displayed to the user. Use this input type with care since the associated data is fully accessible to scripts through the data-binding object model, as well as directly through the element's value.
An example of a bound password is:
<INPUT TYPE="PASSWORD" DATASRC="#DSC1" DATAFLD="password">RADIO
Radio buttons are used to select a single value from a set of alternatives. These can be used to select the value for an enumerated field in a database. One radio button is specified for each of the alternatives using a separate INPUT. The NAME attribute on the INPUT determines the logical grouping of alternatives. One value is bound for all the INPUTs with the same NAME attribute. All members of a group must specify the corresponding DATASRC and DATAFLD attributes.
An example of a bound radio button group is:
<INPUT TYPE="RADIO" NAME="cards" VALUE="mc" DATASRC="#dsoOrders" DATAFLD="cardname">MasterCard <INPUT TYPE=RADIO NAME="cards" VALUE="amex" DATASRC="#dsoOrders" DATAFLD="cardname">American Express <INPUT TYPE="RADIO" NAME="cards" VALUE="visa" DATASRC="#dsoOrders" DATAFLD="cardname" >VisaClick the Show Me button to see a working example.
This feature requires Internet Explorer 4.0 or later. Click the icon below to install the latest version. Then reload this page to view the sample.TEXT
The TEXT type is used as a simple text box. The value of the text box can be bound to a field in the data source using the DATASRC and DATAFLD attributes.
An example of a bound text box is:
<INPUT TYPE="TEXT" DATASRC="#DSC1" DATAFLD="name">
When DATASRC and DATAFLD are specified on an OBJECT, Internet Explorer 4.0 attempts to bind to the object's default property. The defaultbind attribute specified in an object's type information uniquely identifies the default property. If a default property is not specified in this way, Internet Explorer 4.0 uses the property with DISPID 0.
An example of binding the default value on the OBJECT tag is:
<OBJECT ID=oControl1 WIDTH=100 HEIGHT=100
CLASSID="CLSID:xxxxxxxxx-xxxxx-xxxx-xxxx-xxxxxxxxxxxxx"
DATASRC="#DSC1" DATAFLD="controlData">
</OBJECT>
Additionally, Internet Explorer 4.0 supports binding to arbitrary OBJECT properties through the object's contained PARAM tags. Apply the DATASRC and DATAFLD attributes to the PARAM tag. The property's value is initialized with the data supplied by the DSO.
An example of binding the PARAMs on the OBJECT tag is:
<OBJECT ID="oControl1" WIDTH=100 HEIGHT=100
CLASSID="CLSID:xxxxxxxxx-xxxxx-xxxx-xxxx-xxxxxxxxxxxxx">
<PARAM NAME="ForeColor" DATASRC="#DSC1" DATAFLD="forecolor">
<PARAM NAME="BackColor" DATASRC="#DSC1" DATAFLD="backcolor">
</OBJECT>
Bindings can be simultaneously applied to the object's default value as well as its PARAM tags.
A SELECT element supplies the functionality of a drop-down list (combo box) or a list box. Internet Explorer supports binding to a single selected element; binding to multiple selections is not supported.
The items in a SELECT control are specified using OPTION tags. The Dynamic HTML object model defines an options array that corresponds to the collection of OPTION tags for a SELECT. Each OPTION has a corresponding index, text, and value. SELECT has a selectedIndex property that corresponds to the index of the OPTION currently selected. If no item is selected, the selectedIndex is set to -1. The text attribute of an OPTION corresponds to the text following the OPTION tag and represents the string that is displayed for that OPTION in the SELECT. The VALUE attribute provides the value that is to be returned when the HTML form is submitted. Value is also what is stored into the bound column of the data source.
Initially, the selectedIndex property of a bound SELECT element will be set to the index of the value in the options array corresponding to the field of the data source. If the value is not a member of the options array, the index property is set to -1 and, if the SELECT is a combo, no value is displayed. When a user changes the selected item, the corresponding OPTION value (attribute) is used to update the value of the bound field of the data source. Validation events are fired as with other controls.
An example of a bound SELECT is:
<SELECT DATASRC="#DSC1" DATAFLD="cardname"> <OPTION VALUE=mc>MasterCard <OPTION VALUE=amex>American Express <OPTION VALUE=visa>Visa </SELECT>
Click the Show Me button to see a working example.
A TEXTAREA is a multirow text box for data input similar to the INPUT TYPE=text intrinsic. As such it supports the update of the data if the DSO supports the update feature.
An example of a bound TEXTAREA is:
<TEXTAREA DATASRC="#dsoComposer" DATAFLD="bio"></TEXTAREA>
Click the Show Me button to see a working example.
Internet Explorer 4.0 supports binding to the PARAM tags of an APPLET. For example, the following specifies a binding on the xyz property of the application:
<APPLET CODE=somecode>
<PARAM NAME="xyz" VALUE="abc" DATASRC="#Ctrl1" DATAFLD="Column1">
<PARAM NAME="Title" VALUE="BoundApplet">
</APPLET>
The NAME attribute of the PARAM specifies the basename of the Java methods used to get and set the value of the property. This is termed basename since the method of the Java applet to retrieve the value of the property is get<basename>. Correspondingly, the method to set the value of the Java applet is set<basename>. This naming convention is consistent with the JavaBeans 1.0 specification. The applet used in the previous section is expected to have methods named getxyz and setxyz.
Notifications are not fired by the application when property values change. Property changes are only detected when the current record is changed. During this transition, the binding agent interrogates the application and transfers a modified data value, after validation, to the data source. When values are changed directly in the data source, the binding agent is notified by the data source and transfers the value to the application immediately. See the section on data binding events for details about data binding extensions to the event model.
The bound PARAM in the preceding example is the most complicated specification possible. That is, it addresses the case where there is a binding to a property specified by the NAME attribute, and there is a parameter to the application with the same NAME with a corresponding VALUE attribute. This essentially co-mingles two name spaces: the parameter name space for the application and the binding name space, since the NAME attribute is used for both. In such cases, the application ignores the unexpected DATASRC and DATAFLD attributes on the PARAM when fetching a parameter (applications explicitly fetch parameters using the getParameter method), and the binding agent recognizes the attributes and attempts binding using the get and set methods specified above.
The simplest example is one where there is no conflict between the parameter name space and the property name space. An example would be:
<APPLET>
<PARAM NAME="backcolor" DATASRC="#DSC1" DATAFLD="Color">
</APPLET>
Here, the backcolor property has only DATASRC and DATAFLD attributes. No VALUE attribute is specified.
Did you find this topic useful? Suggestions for other topics? Write us!
© 1999 Microsoft Corporation. All rights reserved. Terms of use.
Back to top