cutting@microsoft.com        Download the code (57KB)

Dino Esposito

The Web's Alphabet Soup

s a loyal reader of MIND, you've read about wonderful technologies such as remote scripting, data binding, Active Data Objects (ADO), Remote Data Services (RDS), Extensible Markup Language (XML), Universal Data Access, and Server Scriptlets, just to name a few. Notice that I omitted Active Server Pages (ASP) and Dynamic HTML (DHTML)—a basic knowledge of both is now assumed for just about every Web task today. I'm talking about the advanced stuff that extends from these building blocks.
      In this installment of Cutting Edge, I'll individually examine these newest technologies and how they may affect the way you design and implement Web-based apps. I'll build a Web-based application that uses of all these new technologies. You may be surprised to discover that there's a common thread of logic behind them. Together these technologies provide a powerful, modern toolset for building applications.

A Typical Web App
      Most of today's Web applications roughly follow the schema outlined in Figure 1. A user interface page allows you to submit a query to a remote server. Once you press the Go or Submit button (or whatever launches a remote call), the contents of the user interface fields are posted to an ASP page. This is usually accomplished through a <FORM> tag whose ACTION attribute is the name of the ASP page. Sometimes this <FORM> is included in the same HTML page you're working with. In other cases, it is part of a hyperlinked page that gets invoked after clicking on a specified button. This approach is typical of Web apps that do not rely on HTML for the UI. Such applications might be using ActiveX® documents or a simple HTML page with just an ActiveX control inside to encompass all the UI logic.

Figure 1: Traditional Web-based App Schema

The invoked ASP page accomplishes three basic steps: it retrieves the input parameters through Request.Form, it uses the input parameters to set up and run a SQL query, and it prepares a new HTML page with a portion of the data retrieved. You can distinguish three logical layers, apart from the n-tier architecture of the system: the UI on the client, a first level of code on the server to handle the requests from the client, and a second layer of code that accomplishes the request (almost always retrieving data from storage). On the UI side, you have HTML with a little bit of script. On the server side, you can choose among a variety of solutions depending on the hardware platform and possible portability issues: ASP, ISAPI, Netscape API, Java servlets, or CGI. Behind any of these, there's always a database accessed through ODBC and SQL. Revolutionizing the Web       What's new from Microsoft is a set of updated, improved, and integrated solutions that will populate the three logical layers I mentioned previously. Once and for all, forget any idea of browser independence. To take advantage of the new Web technologies, you absolutely need Microsoft® Internet Explorer 4.0 or higher and Windows NT®.        Figure 2 summarizes the new technologies available for reinventing your Web app. On the client side, you can rely primarily on DHTML to give your front end a cool and attractive look. By using filters, transition effects (see "Slideshows Made Easy with Dynamic HTML"; by Lanie Kurata and Jacqueline Sowell in the May 1998 issue of MIND), hidden DIV sections, trappable mouse events, and above all, the ability to update page content, you can really give life to your Web pages.       On the other hand, the more complex and richly animated an HTML page becomes, the less readable its source code can be. Only tools like Microsoft FrontPage® 98 can cope with them and successfully interpret the content. When programming becomes this intricate, components are the only safe way to go. Thus, DHTML scriptlets are a good compromise to make your pages full-featured as well as reusable, without losing too much in readability and maintainability.       A third important technology that affects the client side of a new Web app is XML. However you design the app, you need to receive streams of data. This was a nonissue until remote scripting came on the scene. Before DHTML, you never had streams of data from the server to interpret—you just had an old page and a new page. Now you have the possibility of updating the content of the current page, and you might receive the data either synchronously or asynchronously.       Here's where XML comes into play. XML provides an excellent way to format the data that's exchanged between different modules on a system. Does your client need a collection of records from the server? Just gather them all, package the content into an XML buffer, and send it across the Net. The receiver will be able to get the data as well as a description and attributes for it. This makes it easier for a client-based component (say, a DHTML scriptlet) to interpret that stream and associate the various chunks of information with specific HTML tags—just like you do on a Visual Basic form when you extrapolate fields from recordsets and link them to graphic controls.       Communication between the client and server is still based on ASP. Everything that you can invoke on the server takes the form of an ASP page. Remote scripting, for instance, allows the client to execute a method of an object located on the server. This object is identified via ASP and JScript. (JScript® is needed here because, unlike VBScript, it's able to create and evaluate dynamic functions through its new operator.) A remote scripting component exposes its programming interface the same way a DHTML scriptlet would, namely via a JScript dynamic function.       Once you figure out a way to establish a direct connection between the client and the server, you also have a channel for sending data. Remote scripting is the middle layer and works more or less as a stub module. It takes care of providing actual data by calling more specialized components. It can also return such data to the client after applying an XML filter. Behind remote scripting there are scriptlets at work (originally called server scriptlets). They are real COM objects (with registration information, version numbers, and ProgIDs) driven by a piece of script code that defines methods and properties following the function-based JScript approach. A server scriptlet is typically an invisible component you can call to do the dirty work. It can issue SQL queries through ADO and return the recordset to the remote scripting layer.       Remote scripting is not the only way to access data without leaving the current page. Another technique relies on data binding. In a nutshell, data binding is an open channel between one or more controls on the client HTML page and a remote ODBC-compliant data source. The client page gets updated incrementally as the data comes in. What's important is that during this time, the user is completely free to do something else—such as filling in other objects in the same page, looking at images, reading text, and so on. In other words, if you linked a <TABLE> with a data-binding source (also known as a DataSource Object, or DSO), you don't have to wait for the entire recordset to download before using the page. Simply put, you have a <TABLE> tag that grows in seconds. More importantly, you don't have to do anything!

Figure 3: Modern Web-based App Schema

If the scenario just described still leaves you a bit bewildered, then have a look at Figure 3, where you'll see how the various pieces of technology arrange themselves and work together to run the application. Starting a New Web Project       Now that I've presented a theoretical model of a new generation of Web applications, let's look at a real-world example. Figure 4 shows the default page of a Web site that provides information about authors, books, and articles. The page is divided into three sections: a header, a body, and a navigational bar. All are implemented as <DIV> sections. From here, you can reach two other pages that let you get data from the server via the two methods outlined in Figure 3: remote scripting and data binding. The overall architecture of the application is the same as what I discussed earlier. The database is the well-known Biblio.mdb, or rather a slightly updated version that includes more entries. The DSN that refers to the database is called Personal Biblio. Let's explore the various layers that form the architecture.

Figure 4: Default Page

The UI Layer       The default page uses lots of DHTML to add some excitement (see Figure 5). In particular, the content of the top frame (which actually isn't a frame at all) may look like a bitmap. However, it is a simple text string

<DIV id="pageHeader" class="pageHeader"> <p>Expoware Soft</p> </DIV>

drawn with the following style:

<style> .pageHeader { position: absolute; width: 100%; height: 75; font-Size: 38; font-Family: Verdana; font-Weight: bold; color: #808080; text-align: center; filter:Shadow(Color=#909090, Direction=135); } </style>

What's new (aside from the absolute positioning) is the Shadow filter style that draws a gray fading shadow behind the text. Color and Direction are arguments that define the final color and the position of the shadow with respect to the text. The actual value denotes the starting angle of the shading. Thus, a value of 135 creates a shadow from the bottom-right. The yellow star, however, is a clickable <IMG>. The body frame is split into two other <DIV> sections called moreinfo and clickhere. They are mutually exclusive in the display. By clicking on the star, you cause the <DIV> named moreinfo to appear (see Figure 6). By clicking on Back everything is restored, and Figure 4 appears. All this magic is due to the display style. By assigning it the value none

<DIV style="display:none"> ... </DIV>

Internet Explorer completely ignores the display style and the page appears as if you never added the previous code.

Figure 6: New Author

The main page has another feature worth mentioning. Move your mouse over the navigational buttons and you'll see some special effects kick in (see Figure 7). This see-through effect is accomplished through the DHTML alpha filter. Here's the code that dynamically changes the style:

<script language="JavaScript" for="qryname" event="onmouseover"> qryname.style.filter = "alpha(opacity=50, style=2)"; </script> <script language="JavaScript" for="qryname" event="onmouseout"> qryname.style.filter = ""; </script>

Figure 7: Special Effect By clicking on the buttons you can load the pages that actually end up calling remote scripting and data binding. In particular, choosing Query By Name requires you to specify an author's name and will obtain their personal information and all the books they've written. On the other hand, choosing SQL Queries gives you the opportunity to issue any SQL statements that can apply to the Personal Biblio data source.

The Server Layer: Remote Scripting       The page that lets you access information about a given author is shown in Figure 8. The 3D Go button is a scriptlet (the hotimage.htm file—see the source code) that simply detects when the mouse is moving over it. It also bubbles its click event to the host page. Through this scriptlet, you can issue a remote call.

Figure 8: Author Information Page

Figure 9 shows the script code for the page. The remote server is

http://servername/rsmind/authinfo.asp

and its code is shown Figure 10. The HTML page calls the DoGetAuthorInfo function, passing the author's name. The line

co = RSExecute( serverURL, "GetAuthorData", sAuthorName );

ensures that the method GetAuthorData defined on the server gets called synchronously. (See the April 1998 installment of Cutting Edge for more information about remote scripting and asynchronous calls.)

Figure 11: XML String

GetAuthorData creates an instance of an ActiveX object called AuthInfo.Biblio, which is a server scriptlet whose source code is found in the file SSAuthinfo.asp. This scriptlet accepts the author's name and actually executes the needed SQL queries via ADO. It returns an array with all the books written by a given author, plus some information about the publisher and the author. The array is then flattened out to an XML string with some descriptive tags. Figure 11 shows the XML string with all of my books. This string is returned to the client page and becomes the content of co.return_value (see Figure 9).       At this point, I need to parse the XML stream and provide a good graphical representation of it. Since this is not a simple task, it's better to isolate it into a new scriptlet. This scriptlet exposes a single XML attribute that points to a local file. To match this, I first save the string to a local file using the FileSystemObject:

file = new ActiveXObject( "Scripting.FileSystemObject" ); h = file.CreateTextFile( localXML, -1 ); h.WriteLine( co.return_value ); h.Close(); authinfoview.XML = localXML;

The scriptlet is then inserted through the following code:

<object id="authinfoview" width="100%" height="100%" data="authinfoviewer.htm" type="text/x-scriptlet"> </object>

Apart from the XML properties, the scriptlet also exposes a DefaultText attribute used to keep track of the text to display when no author is found. Figure 12 shows the scriptlet in action.

Figure 12: Remote Scripting Results

In the scriptlet's window, you can see how the scriptlet formatted the original XML data. To change the way the data is presented, just modify the scriptlet. What I haven't emphasized enough so far is that when you use remote scripting, you never leave the current page! Instead, you simply wait for the data to arrive—the same way you do from a Visual Basic form in a traditional client/server application. The Database Layer: ADO       The server scriptlet accesses the Personal Biblio DSN through ADO and runs a series of queries following the Biblio table structure outlined in Figure 13. To get the same information more efficiently, I could have issued a statement with some nested JOINs instead of multiple SELECTs. The method used minimizes the amount of data transferred. In fact, each recordset is merged into an array and there are no duplicated author's fields for each record. This appeared to be more logical since XML, not the recordset, is the final type of data I'll be moving to the client side.

Figure 13: The Biblio Table Structure

ADO (and ODBC at the lowest level) provides a good abstraction from the actual database being used. You can use a SQL Server™ table as well as any other database for which an ODBC driver exists. The Server Layer: Data Binding       Let's explore an alternative way of getting the same results. Data binding is a mechanism that provides a link between certain HTML tags and a data source. Basically, it consists of an ActiveX control (the DSO controller) placed in the client page that connects to a remote (or local) data source via ODBC.       Currently, you can choose between two flavors of data binding: tabular data control and the more interesting RDS, which is an integral part of the Microsoft Universal Data Access strategy. (For more information on these topics see "Data Binding in Dynamic HTML"; by Rich Rollman in MIND, July 1997 and "Say UDA for All Your Data Access Needs"; by Aaron Skonnard in MIND, April 1998.) In both cases, you have to include an ActiveX control in your page and tell it what to do. RDS lets you link to an ODBC source in the same way as ADO. (This is not a mere coincidence, since RDS is part of ADO.) Once the connection is established you just indicate which HTML tags should be refreshed as soon as the data comes in. In this case, I want to issue simple SQL statements, and I expect a raw recordset to be returned.

Figure 14: Issuing a SQL Query

Data binding is a typical feature you can encapsulate in an HTML component like a scriptlet. Figure 14 shows such a scriptlet in action; its source code can be found in Figure 15. The data binding starts with code like this

<script language="JavaScript"> function DoExecuteStatement( sStatement ) { DBViewer.Connect = "Personal Biblio"; DBViewer.Sql = sStatement; DBViewer.BuddyElement = document.all( "reccount" ); DBViewer.Execute(); } </script>

which it executes after the user clicks on the Go button. I set the connection string and the SQL statement. The BuddyElement attribute relates to an HTML tag whose innerHTML property will be updated by the scriptlet automatically to reflect the number of records found.       The scriptlet body includes a <TABLE> component that will act as the target buffer for all the records. This link is set through the datasrc attribute:

<table datasrc="#rds"></table>

By hooking the ondatasetcomplete event for the RDS control I am informed when the recordset returned by the statement is ready. At this point, I can restructure the table dynamically, adding as many columns as required by the recordset (see Figure 16).

iNumOfFields = rds.recordset.Fields.count; for( i=0; i<iNumOfFields; i++ ) s1 += "<td><span datafld=\"" + rds.recordset.Fields(i).Name + "\"></span></td>"; s2 = "</tr></tbody>";

Each table cell must show the DATAFLD attribute pointing to a specific field in the recordset. I used <SPAN> and <DIV> tags throughout the code to better isolate the various visual components.

Figure 16: A Complex SQL Query

In the sample program, you access the page with data binding by clicking the Query button on the navigational bar. There's a text box in which you can type SQL statements. The same result I got earlier with remote scripting now requires a complex SQL statement like this:

SELECT Authors.Au_ID, Authors.Author, Authors.[Year Born], [Title Author].ISBN, Titles.Title, Titles.[Year Published], Publishers.Name FROM Publishers INNER JOIN (Authors INNER JOIN (Titles INNER JOIN [Title Author] ON Titles.ISBN = [Title Author].ISBN) ON Authors.Au_ID = [Title Author].Au_ID) ON Publishers.PubID = Titles.PubID WHERE Authors.Author Like ‘Esposito%';

Using this code, you can get all the books (including title, ISBN, and publisher) written by all authors who match the word Esposito.       Even though I employed data binding, I didn't have to leave the current page while preparing the data. DHTML made this possible. Reinventing The Web: Next Steps       If you want to upgrade your existing Web application you can follow two steps. First, introduce some DHTML code on the client side. You could leave everything unchanged but add a completely new layer of DHTML-compliant code and rely on some ASP scripts on the server to detect the browser and determine the proper page to send. Second, rely on remote scripting or data binding to connect to the server and get data.       Server scriptlets are a more horizontal technology that is designed to provide server-side goodness for any downstream browser. Server scriptlets, or more simply scriptlets, are nonvisual components with a wide range of potential application. Their use is not strictly tied to having Internet Explorer on the client or Internet Information Server technologies on the server, because they're implemented as COM servers. You can use them wherever you think having script-driven COM components may help. In particular, the Windows® Scripting Host engine will open up an entirely new world to scriptlets (see the June 1998 installment of Cutting Edge for more information).       Of all these fairly new technologies, remote scripting is the most exciting to me. Reinventing the Web using remote scripting doesn't necessarily require Internet Explorer 4.x on the client, since it is based on Java and JScript code. On the other hand, it requires Windows NT on the server—or server that provides full support for ASP. Currently, the major concern in using remote scripting originates from its release status—it's in beta at the time of this writing. The latest version is available at http://www.microsoft.com/scripting, as are all of Microsoft's scripting products. The latest beta of remote scripting works fine, but as for any product in development, you can expect some changes and improvements before it ships.

From the October 1998 issue of Microsoft Interactive Developer.