Data-Binding Architecture

There are four fundamental components to the Dynamic HTML data-binding architecture:

• Data source objects
• Data consumers
• Data binding agent
• Table repetition agent

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

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:

• Tabular Data Control (TDC)
• Remote Data Service (formerly ADC)
• JDBC applet
• XML data source object
• MSHTML data source object

DSOs have several key responsibilities:

• Defining how the data is specified
• Transporting the data to the page
• Possibly manipulating the data
• Possibly relaying changes back to the server

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:

• OLE DB
• OLE DB Simple Provider (OSP)

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

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

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:

• HTTP
• HTTPS
• DCOM
• In-process COM

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.

XML Data Source object

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

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.

HTML data-binding attributes

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.

Data-Consuming HTML elements

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.

• INPUT, TEXTAREA, and LABEL elements The simplest data-bound elements are the INPUT, TEXTAREA, and LABEL elements. Note that you do not have to code these elements inside a FORM to use them. Each element identifies its own DATASRC and DATAFLD attributes, which identify the data source and the data field, respectively. As the current record changes, the text in these elements changes accordingly. The INPUT and TEXTAREA elements can update data as well.
• DIV and SPAN elements These two elements, while read-only, provide novel functionality in that they both support the DATAFORMATAS=HTML property assignment, which causes the bound text to be parsed and presented as HTML text. This provides a mechanism for having parts of the presentation itself stored in a database and displayed in multiple contexts.
• A and IMG Elements The A and IMG elements are "indirect" in that the bound data is a URL. That is, the data is expected to point to a valid HREF (in the case of the A element) or a valid image file (in the case of the IMG element). If you want to bind the text of the A element, you can use a bound SPAN element. Note that the IMG element does not support "blob" image data from the database.
• SELECT and INPUT TYPE=RADIO binding In the previous elements, the interface of the control changed with each record. In SELECT and INPUT TYPE=RADIO controls, the interface is static as you scroll from record to record. What changes is which item in the list is selected for each record. Each OPTION element within a SELECT or each INPUT TYPE=RADIO sharing a NAME attribute has a VALUE attribute which corresponds to legal values in the data. If a given record has no corresponding VALUE in an element, no element is shown as selected.
• TABLE binding We can bind the TABLE element to a recordset and get a complete picture of the contents of that recordset. We have a lot of control over how that table displays the data. Basically, you define your header and a "template" row that describes the way you want the data represented. When Internet Explorer 4.0 displays this table, it repeats the template row for each record in the recordset.

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

Binding Agent

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.

Table Repetition Agent

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.