Dynamic HTML (DHTML) promises to change radically the way developers build Web applications. It empowers the client end of the Web server/browser relationship. The DHTML feature most oriented to the needs of database developers is data binding. Data binding can deliver data asynchronously from a server to a Web browser. This process allows browser users to start interacting with a database much more rapidly because they do not have to wait for the creation of the whole page on the server. Another important data binding innovation is the isolation of the data from the Web page, which makes it easier to perform maintenance tasks on databases shared across multiple Web pages. By storing a local data cache, it is possible to perform standard navigation, sorting, and filtering tasks without returning to a server. This approach speeds a surfer�s experience while reducing network traffic and server load. Users can add, update, and delete records without constantly having to go back to the server for every change. Because data binding can directly couple with a remote data source, it eliminates the need for server-side processing of GET and POST requests.
Standards are rapidly becoming available for this new Web technology. The World Wide Web Consortium (W3C) issued in October 1997 a draft Document Object Model (DOM). Netscape, Microsoft, and other industry leaders participated in the development of the draft. When the final W3C specification appears sometime in 1998, it "will allow programs and scripts to access every element in a document and update the content and structure of documents in a standard way" (quoted from the DOM specification at www.w3.org/TR/WD-DOM/). ECMAScript, issued by the European Computer Manufacturer�s Association (ECMA), is likely to become the standard scripting engine for DHTML. This scripting language is an outgrowth of JavaScript from Netscape and JScript from Microsoft. The final IE 4 release supports both ECMAScript and the draft W3C DOM spec. Netscape pledges support for both ECMAScript and the final version of the DOM as issued by W3C sometime in 1998. As the standards compliance grows among browser developers, the opportunities to apply DHTML will grow.
As I write this, the way Microsoft performs data binding is still proprietary. In all fairness, there is no W3C standard on the topic. The current W3C HTML 4 recommended specification "reserves" Microsoft�s data binding attributes for future use (see www.w3.org). W3C has the option, but not the requirement, to adopt them in its final HTML 4 specification. The chairperson of the W3C DOM committee, Lauren Wood, told me she estimates that a set of specifications will emerge from her committee in late 1998. Those specs may or may not include any data binding attributes, and those attributes may or may not match the current or future Microsoft implementation. Despite all this uncertainty, it is likely that some future DHTML spec will offer better database support than is currently available. Learning the Microsoft implementation will help database developers gain familiarity with performance and appropriate features. There is no alternative to DHTML at this point.
This article introduces data binding by providing an overview of its architecture. Next, it covers three steps that you must take to incorporate data binding in a Web application: designating an object to contain the local data cache, binding page elements to the cache, and writing scripts to support the task.
Figure 1 displays the major architectural landmarks of data binding. A data source object (DSO) sits on a Web page and holds a local data cache. It also links to remote data sources over the Internet or an intranet. Binding attributes link the DSO�s cache to HTML page elements such as td and input type=text. Scripts enable user interactivity with the local cache.
In the first step, a developer must place a DSO on a page. This will often be either an ActiveX control or a Java applet. The local cache is at the very heart of data binding. The DSO can use any transport, including such typical ones as HTTP and simple file I/O. DSOs can link to remote data sources either synchronously or asynchronously. The asynchronous route gives browsers faster interactivity with the data. DSOs available with IE 4 allow it to interface with text, ODBC, XML, and HTML datatypes. The DSO also determines if and how scripts can perform basic sorting, filtering, and database maintenance operations (depending on the DSO, this can mean inserting, updating, and deleting records in the local cache or on a remote data source). DSOs expose methods that permit scripts to manipulate the data in their cache. IE 4 ships with several DSOs, and there is a growing number available at Microsoft�s DSO Gallery. (See the Web resources table on for DSO Gallery URL and other critical resources.) You can even build your own DSO for special situations. The only strict requirement for DSOs is that they provide access to their data via OLE DB or OLE DB Simple Provider APIs. OLE DB is Microsoft�s emerging universal data access standard. It will find its way into Visual Studio during 1998, and Microsoft Office will include it approximately a year later.
In the second step, developers must bind page elements to the local cache. This is how DHTML displays a cache�s data. There are two basic display formats: current record or repeated table. The current record format displays one record at a time. The repeated table format presents all records or a subset of the records in a tabular layout so they look like HTML tables. Many HTML elements support data binding, including img, span, a, button, marquee, select, and textarea.
Two essential attributes (datasrc and datafld) enable data binding. The datasrc attribute links an element to a DSO. It does not designate a specific field within the cache. The datafld attribute builds on the datasrc link to designate a unique field in the cache.
The third step is strictly optional, but you will most often find it necessary. Write scripts (in either ECMAScript or VBScript) to facilitate user interactivity for such activities as record navigation, sorting, and filtering, as well as adding, inserting, and deleting records. You will also find scripts useful for various initialization tasks, such as linking with a remote data source.
Three DSOs ship with IE 4: Tabular Data Control (TDC), Remote Data Service (RDS), and the XML DSO. The TDC supports static text files. The RDS permits dynamic updates to a remote data source. The XML DSO is a Java applet that is a read-only data provider for data in extensible markup language format. Developers can also declare an object that uses a source HTML page as a data resource for a data-bound page.
The TDC is an easy-to-use DSO. It is an ActiveX control that ships with IE 4. It installs on a computer along with the browser and accesses text data files in comma-delimited format. You can use it when your application requires nothing more than offline data browsing. Prepare a program that exports the comma-delimited file from your live database. Then, point your TDC instance at the text file.
Declare the TDC with an object element. The following excerpt shows a sample declaration:
<OBJECT ID=elements CLASSID="clsid:333C7BC4-460F-11D0-BC04-0080C7055A83">
<PARAM NAME="DataURL" VALUE="filename.txt">
<PARAM NAME="UseHeader" VALUE="True">
</OBJECT>
Notice that the declaration takes place within an object tag pair. The CLASSID setting points at the class-identifier for the registered TDC control. The ID is the friendly name for the DSO. Data binding attributes that link the TDC�s cache to a page element will reference the DSO by its friendly name with a leading # prefix. The DataURL parameter is essential. This parameter points at a text data file. The example uses a relative URL. Use this style when the HTML file for your Web page and your data file share a common folder. You could also use an absolute address consisting of a protocol, a URL path, and a file name. The following example references the HTTP protocol, my firm�s Web site, a fictitious virtual directory within the site, and finally the file name:
http://www.cabinc.win.net/DBMSSamples/minielts.txt
The UseHeader parameter takes Boolean values of true and false. Its default value is false. When your application sets it to true, the data file�s first line contains header labels for each column of data.
The TDC supports properties and methods that can be divided into three categories: those for the data file, those for filtering, and those for sorting. The preceding declaration illustrates how to set the DataURL and UseHeader properties at design time. These properties pertain to the file. The Filter property lets you designate one or more fields with criteria for the DSO�s cache. Use the Sort property to specify one or more columns for sorting a cache�s records. In order to invoke new Sort, Filter, or DataURL properties at runtime, invoke the Reset method for the TDC control.
The RDS is a more sophisticated and powerful DSO than the TDC. It is more sophisticated because it requires server and browser components. It is more powerful because it lets you update remote data sources directly. The RDS is suitable for situations where data sources are OLE DB or ODBC compliant. When using RDS, your application needs a SQL statement to specify the cache contents. The RDS empowers developers to deliver real-time update, insert, and delete capabilities in their Web/database applications.
The client RDS, an ActiveX control, installs with IE 4. You can download a version of the client-side RDS that runs with IE 3 at www.microsoft.com/msdn/sdk/inetsdk/help/rds/gs01.htm. The server-based component requires a Windows NT operating system running Microsoft Internet Information Server (IIS) version 3 or later. This reliance on IIS 3 underscores the proprietary nature of Microsoft�s data binding solution. To install the RDS server components, connect your server to the Remote Data Service site. Choose to install the 1.5 version of the software for IE 4 browsers. If your server needs to maintain backward compatibility with IE 3, install the 1.1 version of server software.
Insert the RDS on a Web page by referencing it in an object tag pair. The following sample RDS declaration includes three settings that developers must make available for the DSO to connect to a remote data source. These settings are the Server, Connect, and SQL statement parameters. Developers can set these at design time, as in the example that follows, or at runtime with a script. It is necessary to expose user IDs and passwords in HTML. A user can enter this information on a form while in the process of initiating the data cache.
<OBJECT classid="clsid:BD96C556-65A3-11D0-983A-00C04FC29E33"
ID=dsoComposer HEIGHT=0 WIDTH=0>
<PARAM NAME="Server" VALUE="http://servername">
<PARAM NAME="Connect" VALUE="dsn=dsnName;uid=guest;pwd=">
<PARAM NAME="SQL" VALUE="Select more SQL">[["Select * From Products"]]
</OBJECT>
The RDS exposes different properties and methods from the TDC. The primary difference is that the TDC works with text files and the RDS works with ODBC and OLE DB data sources. Use the Server property to designate the server�s name and the protocol for connecting to it. The Connect property lets you designate connection parameters, such as DSN name. Store a SQL statement in the SQL property to create the data for a DSO�s local cache.
After setting the Server, Connect, and SQL properties, your application can create a disconnected, local recordset by invoking the RDS Refresh method. This, in turn, automatically calls the RDSServer.
DataFactory object that returns a recordset object to the client browser. The RDSServer.DataFactory object is a server-side automation object that receives client requests. It resides on a Web server and provides read/write access to remote data sources. The RDSServer.DataFactory object performs no data validation or business-rule logic. When business-rule validation is necessary, replace the default RDSServer.DataFactory with a custom ActiveX control that includes its data accessibility functionality along with your application�s business-rule logic.
A third DSO that ships with IE 4 is for XML data. This DSO is a Java applet that offers read-only access to XML data. Because of the unique strengths of XML, Microsoft recommends this DSO for presenting hierarchical data, such as sales for a customer. The following example illustrates the declaration format.
<APPLET CODE=com.ms.xml.dso.XMLDSO.class WIDTH=0 HEIGHT=0 ID=xmldso MAYSCRIPT=true> <PARAM NAME="url" VALUE="/msdn/sdk/inetsdk/samples/databind/customer.xml"> </APPLET>
The Code attribute specifies the Java package that implements the DSO. The URL parameter designates the location of the data file that the DSO reads.
In addition to using external ActiveX and Java applets as DSOs, you can define data sets within an HTML document. The formatting is not the same as a standard table block. When Microsoft HTML parses data, it searches for ID attributes that define data set columns in the source document. (Microsoft HTML is the version of HTML that is implemented in IE 4. It includes the tags that support data binding, and it references a corresponding Document Object Model.) The set of unique ID settings defines the columns in a data set. These ID attributes in the source document correspond to a datafld attribute in the bound document. Use an object tag pair in the bound page to reference the source document. The following declaration reveals the general syntax.
<OBJECT ID=DSOname DATA="sourcefilename.htm" HEIGHT=0 WIDTH=0> <>/OBJECT>
Besides those DSOs that ship with IE 4, you can gain access to additional DSOs at the DSO Gallery site. As I write this article, there are four DSOs at the site, with mention of more on the way. You can download DSOs from the site and use them as starting points for custom DSOs. The site�s DSOs suggest some of the diverse uses to which you can put custom DSOs.
One Java DSO, the Calendar applet, presents a calendar in any of 10 different languages, from Chinese and English to Lithuanian and Russian. Users use a select box to choose a language, and they use two buttons to navigate backward and forward one month at a time. The DSO controls the language for expressing the month and days of the week according to the language in the select box. (To do this, the DSO uses OLE DB Simple Provider technology available for Java to reference a database. The code illustrating how to accomplish this is available on the DSO Gallery.)
The Java DSO provides read-only access to remote ODBC-compliant data sources. The DSO permits updates, inserts, and deletes for entries in the local cache. It does not allow revisions to the remote data source. There are two sample applications on the DSO Gallery that let you see the Java DSO in action pulling data from either an Access or an Oracle database. The Internet Client SDK provides more extended documentation on the Java DSO properties.
Another DSO in the gallery is a COM object written in Visual Basic 5.0. This control generates an amortization table in response to three inputs: the loan amount, the loan duration, and the interest rate. In this case, the DSO creates its own data source based on user input. The control supports page navigation that allows the display of 12 months of data at a time.
A second Visual Basic DSO, the Loan Calculator, allows users to transpose the rows and columns of a matrix. This DSO also lets users alter its current data cache by adding two rows and columns. The DSO transforms and grows its data cache with function calls described at the OLE DB Simple Provider site. This DSO is available on the DSO Gallery.
OLE DB Simple Provider is a data binding API. Use it in conjunction with the DSO Gallery samples to learn how to build custom DSOs. The API supports access to string and variant data types arranged in array-like structures exposing row and column entries. OLE DB Simple Provider offers two distinct interfaces: OLEDBSimpleProvider supports data access methods, and OLEDBSimpleProviderListener designates notification functions for data changes. Microsoft offers an online site (see the Web resources table) in the Internet Client SDK that details OLE DB Simple Provider functions. The documentation provides background information on data referencing rules and guidelines for the use of asynchronous data transfer functions. The documentation groups other functions into areas such as searching, retrieving, and setting variant values, as well as deleting and inserting rows.
The DSO makes the data available to a Web page, and the binding attributes link that data to page elements. In a sense, the DSO acts as a pitcher of data. The display formats and the binding attributes combine to determine how the data pours onto the page. With Current Record display, users get to see just a drop (or a record) of it at a time. The Repeated Table design can pour the whole pitcher onto the page at once. Optionally, it can also deposit a cup�s worth of data on the page. Developers determine the cup�s size with the datapagesize setting at design time or its corresponding property at run time.
The Repeated Table design is the most basic display type. This display format relies on the Table block and a div or other block container for displaying individual field values. (The div tag is a container that renders HTML. It can hold any HTML-formatted material, such as a book chapter. By the way, div is not short for division; it is just plain div.) Use the datasrc attribute with the table tag. Recall that this attribute links the table to the local data cache. Set the attribute equal to the DSO ID setting with a # prefix. You specify one row of the table as a template for all rows. Reference a field from your local cache for each cell in the template. Without a datapagesize attribute for the table tag, this displays all rows in the cache. The field elements within a row inherit the datasrc setting from the table tag. The following example shows how to specify a repeated table with one column. Since the datafld attribute does not pertain to the td tag (which represents a cell in a table), you must insert another block tag, such as div, to link the cell to a particular field.
<TABLE datasrc =#DSOID>
<TR><TD><DIV DATAFLD=fieldname></DIV></TD></TR>
</TABLE>
The Current Record format reveals just one record at a time. With this type of display, you must assign a datasrc and a datafld attribute to each page element bound to the local cache. You can arrange data bound elements on a page with traditional table formatting techniques or the newer dynamic positioning settings. Remember that the traditional HTML page layout arranges items on a page by positioning them in table cells. DHTML makes it possible to designate the coordinates for elements on a page. The following example shows one field in a current record display. Notice the span element contains both datasrc and datafld attribute settings. The span tag creates an inline text container that permits to which a page author can assign style settings. Repeat this row for all the other fields in your current record display.
<TABLE> <TR><TD>Field Label:</TD>TD><SPAN datasrc =#DSOID DATAFLD=fieldname></SPAN></TD></TR> </TABLE>
When displaying data with this format, you must include navigation buttons and associated functions to allow users to move through the records in the cache. The recordset method for a DSO returns the ActiveX Data Objects (ADO) recordset. This recordset, in turn, has the normal MoveNext, MovePrevious, MoveFirst, and MoveLast methods for changing the displayed record. The recordset object also has the BOF and EOF properties for determining when a move transfers control to one record before the first record or one record after the last one. Use a script language such as ECMAScript or VBScript to control navigation.
The datapagesize attribute for the table tag applies to the table element in a Repeated Table display. When you set this attribute at design time, it determines how many records pour into the repeated table display. The Loan Calculator DSO sample at the DSO Gallery site illustrates how to use this attribute. First, it initializes the datapagesize attribute to 12. This shows just the first 12 records, or first year of payments. Then, it navigates forward and backward in 12-month blocks. It uses the NextPage and PreviousPage methods to achieve this navigation.
A host of events fire in response to and in association with data binding. These events allow Web developers to write event handler scripts that fine-tune data processing. Event-model support for data binding includes events that fire for the DSO, bound elements, and the page that contains data-bound elements. Use events to determine when and how to access the local data cache, to perform data validation, and to determine the disposition of any changed but uncommitted data.
Three events map DSOs during a change of the data in a local cache. These are ondatasetchanged, ondataavailable, and ondatasetcomplete. Two types of data change can fire the ondatasetchanged event: when the application requests a new data set, and when the application sorts or filters the data in a DSO�s cache. When an application replies to a new data set request asynchronously, the ondatasetchanged fires to signify the availability of metadata, such as the field names. This metadata becomes available prior to the actual data. A DSO can fire the ondataavailable event as it adds data asynchronously to its cache. The data is not completely available until the ondatasetcomplete event triggers. The event object�s reason property reports the outcome of the data request (successful, aborted, or error).
Three events occur in response to data revision attempts from page elements to the local cache. These are onbeforeupdate, onafterupdate, and onerrorupdate. Use the onbeforeupdate event to manage data validation. If an onbeforeupdate event handler returns false, it cancels the update and launches the onerrorupdate event. This second event fires whenever an error occurs as an application attempts to transfer a value from a page element to a cache. Use an onerrorupdate event handler to suppress any system messages associated with the error. The onafterupdate event fires when an application successfully transfers a value from a page element to its local data cache. You can use this event to monitor the status of changes to the cache. The following event handler illustrates an approach to the task. Notice that it handles the event at the document level. This is because the event bubbles up from individual elements on the page. One event handler at the document level can handle events for any page element.
<SCRIPT FOR=document EVENT=onafterupdate> g_fFieldsChanged = g_fFieldsChanged + 1 </SCRIPT>
The onbeforeunload page event is critical for one type of data binding. This event lets you trap uncommitted but changed data in a local cache. Therefore, you only need to work with this event when using the RDS or another DSO that supports real-time updates to a remote data source. Some actions that can fire this event are hyperlink navigation, clicking the Forward or Back buttons, and refreshing a page. All these actions clear the page without storing the contents of a local data cache. Developers cannot cancel this event (as they can onbeforeupdate). Data binding applications can either automatically commit any changed data in a local cache or send a message to a user warning that the last round of changes will be lost.
Data binding is a compelling Web/database technology. It can provide dramatically faster performance because it delivers data asynchronously to a local cache. Once a dataset transfers to a local cache, developers can exploit it with ADO database methodology. This makes possible easy record navigation along with updating, inserting, and deleting in the local cache. DSOs typically enable local filtering and sorting operations. Data binding attributes allow all kinds of interesting ways to present and manage data on a Web page. This article has reviewed two basic display formats, current record and repeated table.
Data binding also empowers browser database applications to update, insert, and delete remote data sources directly. This eliminates the need for you to have local forms that transmit data to server-side programs. The adaptability of this technology is promising.
Data binding guarantees practical business benefits because of its ability to process databases over the Web easily. Nevertheless, the technology is still in its first generation. The documentation does not delve into the topic of what happens when multiple users simultaneously update the same remote data source. My review of the documentation did not uncover answers to such questions as:
| Name | URL | Comments |
|---|---|---|
| Internet Client SDK (Data Binding) | www.microsoft.com/msdn/sdk/inetsdk/help/dhtml/ content/data_binding.htm#dhtml_databind | Major Section in Internet Client SDK devoted to documenting data binding technology |
| Tabular Data Control site | www.microsoft.com/msdn/sdk/inetsdk/help/complib/tabdata/tabdata.htm | Detailed documentation for the TDC |
| Remote Data Service site | www.microsoft.com/msdn/sdk/inetsdk/help/rds/gs01.htm | Detailed documentation for the RDS |
| Data Source Gallery | www.microsoft.com/gallery/files/datasrc/ | Collection of DSOs that illustrate custom DSO development techniques |
| OLE DB Simple Provider API documentation site | www.microsoft.com/msdn/sdk/inetsdk/help/itt/ databind/simpletabulardata.htm#chp_osp | Detailed documentation for building your custom DSOs with OLE DB Simple Provider technology |
| OLE DB site | www.microsoft.com/data/oledb/ | Resources for learning about Microsoft's new universal data access component architecture |
| W3C Extensible Markup Language (XML) Working Group Draft Report | www.w3.org/TR/WD-xml.html | W3C draft XML specification |
| W3C Draft Document Object Model Specification | www.w3.org/TR/WD-DOM/ | Specification that allows scripts and programs to access and update dynamically the content, structure, and the style of documents |
| W3C HTML 4 Recommended Specification | www.w3.org/TR/PR-html40/ | HTML specification that will be consistent with the Document Object Model |
Rick Dobson, Ph.D., is president of CAB Inc., a Web/database/Office development consultancy. Rick is a Microsoft Certified Trainer. His articles appear regularly in Byte and Microsoft Office and Visual Basic for Applications Developer. He is a contributing editor to Microsoft Interactive Developer. You can contact Rick via his firm�s Web site at www.cabinc.win.net.