After completing this chapter, you will
Understand client-side rendering with XSLT.
Understand basic XSLT and general performance guidelines.
Understand how to use event handlers for navigating XSLT-rendered data.
Be able to implement XSLT in custom controls developed with Sys.UI.Control.
In the last few chapters, you learned about components and controls using Sys.Component and Sys.UI.Control. By this point, we’ve covered the basics of AJAX application programming, including data requests using Sys.Net.WebRequest and server-side implementations using Windows Communication Foundation (WCF) SOAP and REST endpoints. In the first part of this chapter, I’ll describe XML and XSLT rendering using the AJAX library, and then in Chapter 10, I’ll examine AJAX navigation challenges and look at the Microsoft AJAX Library’s support for managing browser history. I’ll also show you how to integrate these principles into the case study application to give you an example of these technologies in action.
One of the most powerful tools in the AJAX toolkit is Extensible Stylesheet Language Transformations (XSLT). XSLT is a simple yet powerful language that transforms XML into HTML or other formats using an XSLT processor, which is built into all modern browsers and indirectly supported in the Microsoft AJAX Library.
I introduced XSLT rendering in Chapter 1, using a basic XSLT transform. As you’ve seen in the book so far, XSLT is not required in the AJAX architecture pattern. In many cases, you might end up writing your own rendering logic, as I’ve done with the wiki case study application. However, in most applications, you need to render structured data in lists and provide additional collaborative functionality on top of the rendered data. To do this, you need a rendering technology that is fast, scales well, and is easy to implement and maintain. For special cases, such as advanced data grids, you might end up creating your own controls and creating control instances for each data row in an aggregate control. But for common rendering tasks, creating a control for each instance doesn’t scale well. Instead, templates are ideal for rendering the user interface. These templates can be implemented in a variety of ways, either through JavaScript templates, HTML fragments, or XSLT. In this chapter, we’ll take a deeper look at using XSLT to render data on the client.
Although I can’t possibly cover XSLT in full in a chapter, I’ll cover enough to get you started. With the examples I show and some online documentation, you should have no trouble in beginning to use XSLT in your AJAX applications.
More Information
As an alternative to XSLT, you can use JavaScript client-side template rendering, which is part of the ASP.NET AJAX 4.0 future release. For more information, see http://www.codeplex.com/aspnet. However, it’s my opinion that XSLT is the best choice for client-side rendering for most cases.
From my experience over the past few years, XSLT is a simple approach that makes use of modern tools for developing and debugging, including full support in Microsoft Visual Studio. It’s also a faster approach from a performance perspective because string manipulation in JavaScript can be a relatively slow operation, whereas an XSLT transform happens in native code. XSLT is just one option for client-side rendering, however. Choose whichever technology works best for you and your application.
Real World
At NewsGator, we’ve used XML and XSLT in production AJAX code for several years and have found it to be the fastest, simplest, and most powerful and supportable rendering technology for AJAX applications. We use this chapter’s technique extensively in the NewsGator Enterprise and NewsGator Social Sites product lines.
Although the Microsoft AJAX Library has no direct support for XSLT, XSLT is supported either through Microsoft XML Core Services technology (MSXML) or native browser technology in non-Microsoft browsers. This means that XML code must account for two XML processing models, either MSXML or the native browser’s implementation. Internet Explorer 8 will also use native browser methods for XSLT, so very soon MSXML will be used only for backward compatibility in Internet Explorer 6 and 7. The interfaces for both XML models are similar, with a few distinctions that I’ll cover in this section. Both XML models are encapsulated in the Sys.Net.XMLDOM object in the Microsoft AJAX Library, which is used in the network stack when receiving XML from Web services. However, you need to write a few methods for cross-browser XSLT support for use with the Microsoft AJAX Library.
Figure 9-1 illustrates the role of XSLT in the AJAX application. XSLT is an XML markup language that we’ll use to transform XML into HTML that will be added to the browser. For example, you might get a list of products in XML format from a REST service endpoint implemented with WCF.
Keep in mind that client-side XSLT transform files should be simple and should not contain any compiled XSLT extensions, external references, or linked XSLT files. The supported client-side XSLT library is a subset of what you can do in .NET code, so keep it simple. XSLT can also be confusing to developers who are not used to it, so keeping it simple helps the rest of your development team as well.
Keeping your XSLT code simple will address most compatibility issues, but you should also test your XSLT logic in the browsers you want to support. The following guidelines will help you write an XSLT that can run successfully across multiple browsers:
Avoid external references, and use self-contained XSLT files. Linked XSLT files will not be loaded in the browser, and this is not a technique you can use with an AJAX application. As an alternative, you can merge XSLT files on the server to implement shared XSLT resources.
Test any XSLT functions you use in all supported browsers. Only the simplest XSLT functions are universally supported in the browser. Specifically, string functions are not universally implemented.
Don’t include JavaScript in the XSLT output. If you do, there’s a high likelihood of generating invalid JavaScript when you use real data.
Create one XSLT file for each supported view of a data schema.
Above all, keep your XSLT small and lightweight. Ideally, the XSLT file should be less than 200 lines of code, although this is just a guideline from my experience.
More Information
Although I’ve found the browser’s built-in XSLT support to be sufficient, Google has a robust XSLT library for AJAX available under a BSD-style license. You might want to look at Google’s AJAXSLT project at http://goog-ajaxslt.sourceforge.net/.