There are four fundamental components to the Dynamic HTML data-binding architecture:
Data source objects (DSOs) provide the data to the page, data consumers display the data on the page, and the data binding and table repetition agents ensure that the DSOs and the data consumers are synchronized. Figure 16-1 shows the data-binding architecture.
Notice in Figure 16-1 that all four of these components must be present within the HTML page in Internet Explorer 4.0. Even the DSO is an object that needs to be placed on the page, usually as a Microsoft ActiveX control or Java applet.
Figure 16-1. Data-binding architecture.
Data source objects are those entities that expose data from some server in a regular row-by-column orientation. Internet Explorer 4.0 ships with a number of DSOs, including the following:
DSOs have several key responsibilities:
Data can be transported to the page using any protocol desired by the DSO developer. Additionally, the data can be transferred either synchronously or asynchronously. Asynchronous transmission is the recommended method since this way the end user doesn't have to wait for data as it arrives on the page.
Depending on the provider and the nature of the data, updating the data might not be necessary. Many data providers support read-only data to the page. Note that the transport and manipulation of the data is at the provider's discretion. The only "real" requirement is that the provider exposes the data through one of two APIs:
Following these minimal requirements allows Internet Explorer 4.0 to manage the binding of your source to the bindable data elements on a page.
We'll now look at three sample DSOs: the Tabular Data Control, the Remote Data Service, and the XML data source object.
The Tabular Data Control (TDC) is an ActiveX control provided with Internet Explorer 4.0 that takes its data from an input file. This file is normally a comma-delimited text file with carriage returns at the end of each record. However, if necessary you can instruct the TDC to parse on different delimiter characters of your choice. Note that the default format (commas and carriage returns) is the most common export option on most popular database tools. You can specify the TDC object within your HTML page, as in the following example:
<OBJECT id=TDC classid="clsid:333C7BC4-460F-11D0-BC04-0080C7055A83" height=0 width=0> <PARAM NAME="DataURL" VALUE="customers.csv "> <PARAM NAME="UseHeader" VALUE="True"> </OBJECT>
You can tell the TDC that the first record in the file is information about the rest of the records, or metadata. This is achieved by setting the UseHeader property to True in the <PARAM> tag. You can include field names and data type information in this first record. The delimiters used by the rest of the field separate each field description, but if there is both a field name and data type information, they are separated by a colon.
Having your data come from text files might not seem very interesting, but it's not as limiting as you might first suspect. You can bind the TDC to an ASP file, for example, and have the server dynamically generate the data for you. The minimum requirement is to have the ASP file return text appropriate for the client object by specifying the text/plain mime type as in the following example:
<%@ Language="JScript"%> <% Response.ContentType = "text/plain"; Response.Write("Example,Location,Type\n"); Response.Write( "Current record example,examples/CurrentRecord.ASP,data\n");
In this example, the text to be sent to the client is hardcoded, but we could have created an ActiveX Data Objects (ADO) recordset, retrieved data into the recordset, and then written out the recordset rows and columns instead.
The object model for the TDC includes several file properties for describing the location of the data file and its format, plus properties for filtering and sorting the data. A reset method is used to apply the new filter or the new sort order so that it refreshes the HTML elements on the page. Table 16-1 shows the properties and methods for the TDC control.
Table 16-1. Properties and methods for the Tabular Data Control.
Property/Method Name | Type | Description |
---|---|---|
CharSet | Property | Identifies the character set used by the data file. The default character set is latin1. |
DataURL | Property | Specifies the location of the data file as a URL. |
EscapeChar | Property | Identifies the character to be used as an escape character in the data file. There is no default escape character. |
FieldDelim | Property | Identifies the character that is used to mark the end of a field in the data file. The default character is the comma (,). |
Language | Property | Specifies the language used to generate the data file. (This specifier uses the HTML standard code based on ISO 369.) The default specifier is eng-us. |
TextQualifier | Property | Specifies the optional character that surrounds a field. |
RowDelim | Property | Identifies the character used to mark the end of each row of data. The default character is the newline (NL) character. |
UseHeader | Property | Specifies whether the first line of the data file contains header information. The default value is FALSE. |
Sort | Property | Sorts the data. Specified using a semicolon-delimited list of column names. Prefix with a plus (+) symbol for ascending order or a minus (-) symbol for descending order. |
Filter | Property | Filters the data. |
Reset | Method | Sorts and/or filters the data and refreshes the contents of the HTML elements bound to the data supplied by the TDC. |
You can find the source code for the TDC on the Internet Client SDK. There is also plenty of reference information and sample code on the Microsoft Web site. The section "Using the Tabular Data Control" later in this chapter also gives some examples of how to use this control within your applications.
Remote Data Service (RDS—formerly known as ADC) is a bit more robust and complex than the TDC. RDS provides bindable recordsets to the client much as the TDC does but relies on a connection to some "real" back-end database and permits updates as well.
RDS is a data-marshaling technology. The client-side component, called the RDS.DataControl object, interacts with a server-side component to move the records from server to client and back. Nominally, the server-side component is called the RDS.DataFactory object, but you can replace this object with one (or more) of your own creation.
The RDS.DataControl object is the client-side component responsible for interacting with the Web page. Under most circumstances, you simply create the object on the page with an <OBJECT> tag and allow it to manage all the interactions with the server:
<OBJECT id=rowData classid="clsid:BD96C556-65A3-11D0-983A-00C04FC29E33"> <PARAM name="Server" value="http://www.myserver.com"> <PARAM name="Connect" value="DSN=mydsn"> <PARAM name="SQL" value="select * from products"> </OBJECT>
Of course, you can specify these values at run time, too. Once you've made changes that you want to keep, you call the RDS.DataControl object's SubmitChanges method and only the modified records are returned to the server.
The RDS.DataFactory object is the default middle-tier component in RDS. It's the workhorse of the relationship, responsible for interacting with the client-side RDS.DataControl object, retrieving data from the ODBC data- base, and updating that database with the modified records returned by the RDS.DataControl object. However, the RDS.DataFactory object is relatively simple. It cannot reconcile update conflicts, for example, or negotiate with the data server in any but the simplest way. If it is unsuitable for your needs, you can replace it with a business server of your own design.
The RDS.DataControl and RDS.DataFactory objects communicate across one of four protocols:
You specify which protocol to use with the Server property on the RDS.DataControl object. The recordset exchanged between the RDS.DataControl object and the RDS.DataFactory object is marshaled (in the case of Web servers) into a special MIME format called table datagrams. This marshaling is transparent to the applications using the RDS objects.
The XML data source object allows you to display data from an XML file within your Web pages. XML stands for eXtensible Markup Language. One of the key features of XML is that is describes the format of data. In fact, it is the universal format for data on the Web. Being extensible means that you can create whatever tags you want within your XML code—you are not limited by the predefined tags of HTML. Rather than replacing HTML, XML is a complementary format that has many areas of application. The following is an example of an XML file:
<?XML VERSION="1.0" RMD="NONE"?> <VALUES> <ITEM> <FIRST>1</FIRST> <SECOND>2</SECOND> </ITEM> <ITEM> <FIRST>3</FIRST> <SECOND>4</SECOND> </ITEM> </VALUES> </XML>
The XML data source object is particularly useful for displaying hierarchical data on your Web pages. The XML data source object is implemented as a Java applet and can be obtained from the Microsoft Web site by downloading the XML Parser in Java. The class file that implements the XML data source object is named XMLDSO.class.
The Microsoft Web site has plenty of information on XML, including information about XML support in Internet Explorer 4.0 and in Internet Explorer 5.0 Beta. Later in this chapter, we'll take a look at how to use the XML data source object in a sample HTML page.
Data Consumers are elements on an HTML page that render the data supplied by the DSO. Elements can be intrinsic HTML elements or custom Java applets and ActiveX controls.
To enable intrinsic HTML elements to render data from a DSO, Microsoft has introduced four attributes that make up the entire HTML interface to data binding. Table 16-2 lists the four attributes.
Table 16-2. HTML data-binding attributes.
Attribute | Description |
---|---|
DATASRC | Specifies which element on the page (by ID) contains the data you want the element bound to. |
DATAFLD | Specifies which field (by name) in the data you want the element bound to. |
DATAFORMATAS | Specifies the format you want the data rendered in. This can be "text" for plain text or numeric data or "html" if the data contains HTML markup in it. The data will be dynamically parsed and rendered on the page for each record displayed. |
DATAPAGESIZE | For use with tables, specifies how many rows of data to display at once. Two additional methods, nextPage and previousPage, allow you to page through the records at run time. |
Most elements that we'll look at are bound to the "current row" in the data source. Some specialized components, like grids and tables, know how to use the entire recordset. Presently, the only "native" HTML element that uses the entire recordset is the TABLE element. All the other elements bind to the current record only. The data-consuming HTML elements are shown in the following list of items.
You don't have to stop at a single template row. Internet Explorer 4.0 will repeat everything in the TBODY (explicitly or implicitly defined) for each record. When a recordset has lots of rows, it is sometimes appropriate to show the data in chunks rather than having one long scrolling view. You can specify the size of the chunk to display with the DATAPAGESIZE attribute on the TABLE element.
In addition to the HTML elements listed above, there are many more that can be bound to a recordset. Table 16-3 lists the complete set of bindable elements, describes whether they are updatable and whether they can render HTML, and gives a description of the bound property of the element.
Table 16-3. Bindable HTML elements.
Element | Updatable | Renders HTML | Bound Property |
---|---|---|---|
A | False | False | href |
APPLET | True | False | property value via PARAM |
BUTTON | False | True | innerText, innerHTML |
DIV | False | True | innerText, innerHTML |
FRAME | False | False | src |
IFRAME | False | False | src |
IMG | False | False | src |
INPUT TYPE=CHECKBOX | True | False | checked |
INPUT TYPE=CHECKBOX | True | False | checked |
INPUT TYPE=HIDDEN | True | False | value |
INPUT TYPE=LABEL | True | False | value |
INPUT TYPE=PASSWORD | True | False | value |
INPUT TYPE=RADIO | True | False | checked |
INPUT TYPE=TEXT | True | False | value |
LABEL | False | True | innerText, innerHTML |
MARQUEE | False | True | innerText, innerHTML |
SELECT | True | False | obj.options(obj.selected-Index).text |
SPAN | False | True | innerText, innerHTML |
TEXTAREA | True | False | value |
The part of the DHTML data-binding architecture that glues the HTML elements to the data sources is the binding agent in Internet Explorer 4.0. It is implemented by mshtml.dll, which is the HTML viewer for Internet Explorer. The binding agent is responsible for managing the relationship between the DSOs and data consumers to ensure that they are always synchronized.
The binding agent actually fires scriptable events that the Web author can take advantage of. These signal various changes in the state of the data between the DSOs and their data consumers.
The table repetition agent works with data consumers that present tabular data such as the HTML TABLE element. It ensures that the entire data set is repeated properly by the data consumer. For individual elements, it relies on the data binding agent to ensure synchronization.