| Microsoft XML Core Services (MSXML) 5.0 for Microsoft Office - XSLT Developer's Guide |  |
| Microsoft XML Core Services (MSXML) 5.0 for Microsoft Office - XSLT Developer's Guide | |
XSLT running on the client can be an effective way of creating applications that require a minimal amount of interaction with a server. After the XML, XSLT, and (in some cases) HTML files are downloaded to the client, all or most operations are carried out on the client host. This usually means more responsive user interactions.
The major drawback of client-side XSLT is that you, the XSLT developer, will have to deal with potential browser incompatibility issues. Therefore, client-side XSLT is best for applications running on an intranet, where it is possible to establish a consistent environment for creating and deploying applications.
To use XML data islands with client-side XSLT, you need MXSML 3.0 or later, which supports the XSLT standards, and Internet Explorer 5.0 and later, which supports XML data islands.
The HTML file in the next topic, DataIsland.htm, shows how to use XML data islands in a client-side XSLT application. An XML data island is represented by an <XML>...</XML> tag in an HTML page. Remember that XML data islands are HTML elements, or DHTML DOM objects when used in a script. This HTML tag can have two attributes: ID and SRC. ID serves as the identifier of the DOM object, and SRC can be used to load an XML document from a specified file.
In this example, there are two XML data islands—that is, two <XML>...</XML> tags. One is identified as book_catalog and holds the XML source document. The other is identified as catalog_filter and holds the XSLT style sheet used to transform book_catalog. Here one XML document (catalog_filter) is hard-coded into the XML data island. The other (book_catalog) reads from an external XML file (book_catalog.xml). To retrieve the XML DOM object from an XML data island, use the XMLDocument property on the data island. For example, catalog_filter.XMLDocument returns the XML DOM object for the XSLT style sheet.
In the DataIsland.htm sample file, the JavaScript code for transforming the XSLT is quite similar to the code used in the server version in Using ASP with XSLT Processor and Template Objects, with a few notable differences. The showGenre() function (renamed from main() in the server version) takes the genre name as a parameter, which lets it modify the contents of a DIV element (called catalog_table) when the select list box's value is changed. This function passes references to the two data islands book_catalog and catalog_filter directly, rather than passing file names. The transformData() function returns the resulting transformed data as an XML object, rather than sending the output to the Response object. This is because the Server.Response object can take an XML DOM stream as input, but the innerHTML property can only take a string.
Both loadSource() and getProcessor() have also been modified to take into account the data island source of the information, and getProcessor() now uses a local variable to store the XSLT processor object, rather than a session variable. Otherwise, the two are quite similar.
The only changes from the XSLT in Using ASP with XSLT Processor and Template Objects are as follows:
<DIV> element, rather than in the full <HTML> wrapper. This has already been declared on the client. onchange attribute of the <SELECT> list box has been changed from a URL call to the command showGenre(this.value). This command will update the table to reflect the selected genre.This example brings up a number of points about working with XSLT on the client:
showGenre function actually contains code specific to a single style sheet and data source. By maintaining this modularity, you can create other functions that use different sources or transformations in the same page—a navigation bar, for example, or a menu—without functions that transform each component separately.SRC attribute on data islands to load both data and transformations from the server in response to changing conditions on the client. For example, an XML document containing sales figures could have a default table translation, but could be converted into a chart by changing the SRC attribute of the transformation data island to reflect a chart.xsl document on the server. Then, the transformation could be applied using the same interface described above. Similarly, live data from a SQL Server 2000 URL call could be retrieved into a data island via the SRC attribute (the specific parameters determined from form elements), and could then be reformatted by the existing transformation on the client.