Looking at the sheer volume of data about XSLT, you might think you need to be a rocket scientist or code junkie to make XSLT work, but you don't have to be an XSLT expert to get the job done with the minimalist, practical approach to XSLT that I show in this article. First, consider that XSLT builds on XSL, which is a stylesheet language for XML files. An application usually specifies XSL files to a parser, which uses the file's XSL declarations and script to process XML data. You can think of XSL as a sort of controller that determines how to render XML. The result of the parser's XSL-to-XML process is an output file or stream that conforms to the XSL declarations and script.
You can work with XSL in a couple of ways. You can start by using Notepad or a text editor to generate XSL, then test the XSL in your application's code. But a better approach is to use a tool that lets you test the XML and XSL without accessing the database or having to run your application each time. Without one of these tools, working with XML can be exasperating because of its idiosyncrasies. For example, XML is case-sensitive. If you use a text editor to build XML or XSL files, you risk using incorrect case and thereby creating code that doesn't work.
XSLTester is an open-source tool that you can download from http://www.vbxml.com. Figure 2 shows this tool with the incoming XML in the left pane and the resulting XML after parsing in the right pane. To use my test XML with XSLTester, I created part of the ASP code for this article's application. This code generated an XML stream that I then saved to a file and used with the XSLT file. Using Microsoft Internet Explorer (IE) 5.5, I copied the XML from the output stream into XSLTester's XML Document window. I used this output as a working XML file for testing.
Next, I opened the Style Sheet view by selecting View, StyleSheet Document. I added Listing 1's XSLT code for the customer to this pane, then saved the stylesheet as ProductsALFKI.xsl. (ALFKI is the CustomerID for the test customer.) In the XSLT code, all XSL files are stored in XML, as Listing 1 shows. The XSLT code starts with the standard XML declaration, then declares the XSL namespace. The next code section does all the work of transforming the document. The match = "/" statement tells the parser to process all elements in the incoming XML. The next line outputs the starting <products> tag, which is the root tag for the output document.
Next is the for-each declarative block of code. The parser executes the statements in the block once for each element in the SELECT part of the statement. In this case, all Product elements under the Products root are selected. The code then outputs the Product tag for the current element.
The next few lines output each of the elements that have a product. The format is the same for each element. The first part of the statement outputs the element tag name. Then the value-of select statement selects the particular element to output and extracts its value. The closing element tag completes the statement. You can see the format in the ProductID statement:
<productid><xsl:value-of select="ProductID"/></productid>
For a ProductID with a value of 18, you'd get the output
<productid>18</productid>
The remainder of the script closes all tags, including the <Product> and <products> tags and the XSL tags.
After you create and save the XSLT code, you're ready to test it. You can use a tool like XSLTester to test and tweak your XML and XSL/XSLT code. When you're satisfied that the code is correct, you can implement it programmatically, as you'll see in a moment.
To test the XSLT code, click Transform on the XSL-Tester toolbar. XSLTester processes the XSLT against the XML file and shows the output in the Transform Output window. If your XML or XSL/XSLT code contains any errors, the Transform Output window reports them.
You can apply different XSLT files against the same XML and get different results. In the case of Company X, we need to output several different XML streams for different customers. In fact, we don't know how many streams we might need over time or in what formats.
To handle the various customer requests, the application uses a separate XSLT file for each user. The XSLT files are stored in the Web site's XSLTCustomer folder. Each XSLT file is named Productsxxxxx.xsl, where xxxxx is the CustomerID field. For example, the customer with the ID of ALFKI would have an XSLT file called ProductsALFKI.xsl. This filename separates the XSLT code for each customer, and the Products prefix separates the XSLT code for Products.
Listing 2 shows the XSLT for the CustomerID BOLID. The only difference between the XSLT files in Listings 1 and 2 is that Listing 2 doesn't have the <UnitsOnOrder> tag. As a result, the XML output for BOLID doesn't have a UnitsOnOrder element.
These two XSLT files show that you can tailor the output from a database without touching the database or any other code. Just change the XSLT file, and you can have a new format for each customer.
Creating the ASP
So, how do you tie the XSLT code and the ASP code together? That's where a standard ASP script comes in. In the sample application, I created a reference to ADO in Visual InterDev. This reference puts a metatag in the global.asa file referencing the ADO type library, allowing the use of ADO constants in my script. Listing 3 shows the ReqProc.asp code, which handles all processing and management of the data-transformation process. A customer simply passes in a URL to receive a custom-tailored XML stream.
The ASP code in Listing 3 begins at callout A by declaring some variables. I commented out the Response.Buffer property during testing. By default, Internet Information Services (IIS) 5.0 turns buffering on, which results in unclear error messages. During development, I usually turn off buffering in the page, then turn it back on by commenting out the line when I know the code works. Also, note that the code sets the Response object's ContentType property to return XML, instead of the default HTML, with the statement
response.ContentType = "text/xml"
This statement is important because the application is sending not HTML but a text stream.
Prev. page
1
[2]
3
next page 
