Authoring Data Binding for Other Browsers

This article guides Web authors through the process of developing pages that support data binding while still maintaining compatibility with down-level browsers.

When writing content for the Internet, Web authors are often interested in reaching the widest possible audience, and that means creating content that works with the myriad of available browsers. This section shows authors how to use server scripts to construct pages that are targeted toward both Microsoft Internet Explorer 4.0 and other down-level browsers. By detecting the user agent on the server, Web authors can provide a superior user experience by taking advantage of the data binding features in Internet Explorer 4.0 and still maintain compatibility with other clients that do not support data binding.

Most pages that deal with data provide the user with one or more of the following capabilities:

• Displaying the current record. Navigational support allows the user to sequentially view additional records.
• Displaying all the records that meet a given criteria. These records are typically displayed in tabular format.
• Updating the data. Elements on the page can be edited, and changes can be synchronized with the database.

Given these features, the Web author should consider the implementation of four functional areas so that they leverage Internet Explorer 4.0 and are still compatible with other browsers:

• Generating a Template on the Server
• Conditionally Supplying Data Source Objects
• Scripting the User Interface
• Supporting Data Update

Generating a Template on the Server

Typically, a template processor, such as Active Server Pages (ASP), is used to generate HTML on the server before sending it to the client. The template processor accesses the data and expands the template into an HTML page that contains the data. To take advantage of the Internet Explorer 4.0 data binding features, authors should take the following steps when authoring their pages:

• Isolate the elements on the page into groups of bound elements and static elements. To accomplish this, break the page into frames, or isolate portions of the page using the div element.
• For current record functionality:
  1. Write a server-side template that displays the bound elements in the page.
  2. Within this template, differentiate between browsers as follows:
     • For Internet Explorer 4.0, write out the elements with the data binding attributes.
     • For other browsers, perform the same operations as today. That is, expand the template with a single record and manage state on the server so a page with the next and previous records can be sent to users when requested.
• For table repetition functionality:
  1. For Internet Explorer 4.0, write out only the table template with the data binding attributes.
  2. For other browsers, perform the same operations as today. That is, expand the table on the server and generate the HTML.

Examples

The following examples demonstrate current record functionality and table repetition.

Current record functionality

When Windows Internet Explorer is the browser, include the current record template in the page.

First create a frame set as the base document.

<FRAMESET ROWS="20%, 50%, 30%">
<FRAME SRC="nav.htm" NAME="nav_frame" SCROLLING=NO NORESIZE>
<FRAME SRC="product.asp" NAME="product_frame" SCROLLING=NO NORESIZE>
<FRAME SRC="similar.asp" NAME="similar_frame" SCROLLING=YES NORESIZE>
</FRAMESET>

In the server-side script, author code to conditionally build the page.

.
.
.
<DIV DATASRC="#ProductList" DATAFLD="Product_Title">
    <% If Not IsIE4OrLater() Then %> <%= RSProductList("Product_Title") %>
    <% End If %>
</DIV>

<HR>

<H2>Overview</H2>
.
.
.
Price: <INPUT TYPE=TEXT DATASRC=#ProductList DATAFLD="Column9" 
    <% If Not IsIE4OrLater() Then %>VALUE=<%= RSProductList("Price")%>     
    <% End If %>>
.
.
.

RSProductList is a reference to a recordset opened at the start of the page (not shown). This recordset is only created on the server if Internet Explorer 4.0 is not the browser.

When Internet Explorer 4.0 is not being used, the div is filled with data from the Title field in the database, and the value of the input tag is set to the value supplied by the recordset. When Internet Explorer 4.0 is used, these elements are synchronized with data supplied by the data source object on the client side. The DATASRC attribute is applied in both cases, since down-level browsers ignore unrecognized tags. Code to insert a data source object when the browser is Internet Explorer 4.0 is shown below.

Table Repetition

When Internet Explorer 4.0 is the browser, the frame identified as similar_frame in the above frameSet example contains a template in which the table containing the list of similar products is bound on the client.

The code for the table follows:

<TABLE DATASRC="#SimilarList">
  <% If Not IsIE4OrLater() Then %>
    <% Do While Not RsSimilarList.EOF %>
      <TR> <TD><%= RsSimilarList("Product Name") %></TD> <TD><%= RsSimilarList("Price") %></TD>
      </TR>
    <% RsSimilarList.MoveNext
       Loop
    %>
  <% Else %>
      <TR> <TD><SPAN DATAFLD="#Product_Title"></SPAN></TD> <TD><SPAN DATAFLD="#Price"></SPAN></TD>
      </TR>
  <% End If %>
</TABLE>

When Internet Explorer 4.0 is not the client browser, the server expands the table with the rows on the server. When Internet Explorer 4.0 is the browser, data binding is used. In either case, the DATASRC attribute is applied to the table because down-level browsers simply ignore it.

Conditionally Supplying Data Source Objects

To enable data binding on the client, Internet Explorer 4.0 uses a data source object (DSO) on the page to supply the data. Other browsers rely on server processing to merge data from a database into an HTML template. A number of approaches can be used to conditionally include the DSO on the page:

Examples

Write a conditional statement in the server script that includes the DSO only when Internet Explorer 4.0 is detected as the browser.

<% If IsIE4OrLater() Then %>
    <OBJECT ID=DSC1 CLASSID="clsid:..."> <PARAM 
    </OBJECT>
<% End If %> 

Write client-side script that first checks the browser version and then dynamically adds the object to the page if appropriate. The following code relies upon the existence of a div element as a placeholder and sets its innerHTML property to an object tag represented by a Tabular Data Control.

<SCRIPT>
if (((navigator.appVersion.indexOf("4.0")>0)
    && (navigator.appVersion.indexOf("MSIE"))>0)) divDSO.innerHTML = "<OBJECT      classid="clsid:333C7BC4-460F-11D0-BC04-0080C7055A83"     ID=tdcComposers HEIGHT=0 WIDTH=0>         <PARAM NAME="DataURL" VALUE="composer.csv">         <PARAM NAME="UseHeader" VALUE="True">     </OBJECT>";
</SCRIPT> 

Include the object tag regardless of the browser type. Non-Internet Explorer 4.0 browsers will ignore the component.

Scripting the User Interface

Since Internet Explorer 4.0 performs all data operations such as navigation on the client, while other browsers require a round-trip to the server and a new page to be rendered, authors should detect the user agent and script user interface elements to work in both scenarios.

Example

The following example illustrates event-handling code behind a button that moves to the next record in the data set. This script can be used on all browsers.

<SCRIPT FOR=cmdNext EVENT=onclick>
    if (((navigator.appVersion.indexOf("4.0")>0) &&     (navigator.appVersion.indexOf("MSIE"))>0)) document.product_frame.dsc1.recordset.MoveNext();
    else <!-- ask server for new page containing next record -->
</SCRIPT>

Supporting Data Update

The current model for presenting data to users for update requires writing a form and then using the HTML SUBMIT functionality to send the updates to the server, where a server process changes the values in the database. A more detailed look at this model follows:

1. A page is displayed on the client consisting of a form page containing elements for user input as well as a Submit button. The values of the elements are set to the current values in the database.
2. After the user completes the edits, she clicks the Submit button.
3. All the data on the form is sent to a server process (CGI, ISAPI, ASP). The process determines which data was changed and updates the database appropriately.
4. The process returns an HTML page to the browser indicating the success or failure of the update.

To incorporate the Internet Explorer 4.0 data binding model into this scenario, the author can do the following:

1. Add a data source object (DSO) that supports data update to the page.
2. Use the data binding extensions to bind the user input elements on the page to the DSO.
3. Allow the user to modify the data.
4. Provide the user with an element, such as a button, that calls the DSO-specific method that commits changes and updates the database. For Remote Data Service (RDS)  this method is SubmitChanges.

Using Internet Explorer 4.0, the user remains on the page to do subsequent processing. A new page is not required because changes are committed to the data on the back end.

Example

In the example scenario, the price of the product is displayed. The user can edit this price by changing the data in the text box. This behavior is identical in all browsers. The key difference is the code behind the button that submits the data. In Internet Explorer 4.0, this button calls the DSO-specific method that commits the changes. Other browsers require the use of a Submit button.

The script for a Submit button follows:

<SCRIPT>
  <SCRIPT FOR=cmdSubmit EVENT=onclick>
  {
    if (((navigator.appVersion.indexOf("4.0")>0) &&       (navigator.appVersion.indexOf("MSIE"))>0))
    {
      document.ProductList.SubmitChanges();
      return false; // disable default processing
    }
  }
</SCRIPT>