XML Benefits | XML Programming Bible

XML can be used in all facets of an application's UI to enforce consistency and offer improved extensibility. By separating content from presentation, XML can help maintain a natural division between the roles of content development and aesthetic design. In this section we will look at various ways in which XML can be incorporated into UI design.

The Controller Pattern Revisited

In Chapter 5 we saw how XML and XSLT can streamline the design, development, and ongoing maintenance of a corporate Web site. At the core of the site was an implementation of the controller design pattern. The idea behind this pattern was to route all requests to the underlying system through a single ASP. This page acted as a proxy for the user, stepping in to render the page before it was returned to the browser.

By architecting a Web application in this way, designers can leverage XML and XSLT to split the process of page construction and presentation into separate tasks. The following sequence describes the chain of events that is initiated whenever a user requests a new page inside the Web application.

The user issues a request to the controller, sending in the name of the page they want to see as well as any contextual information (for example, record IDs, user IDs, etc) that page might need to do its job (for example, see http://www.noverant.com/controller.asp?view=cddetail&cdid=10013).
The controller redirects the request to a page handler that assembles the view the user requested (for example, cddetail1.asp). Like any ASP, the handler might query a database, read a file from the Web server's file system, or even call another URL to gather the data to be shown on the page. Unlike normal ASP pages, however, the handler does not build an HTML document. Instead, it creates an XML document whose structure is specific to the application and was dictated by the application's UI architect.
The page handler returns the page's XML content back to the controller. Now that the controller has an abstract XML version of the page, it must transform the XML version into a form suitable for viewing on the user's browser (for example, HTML). The controller delegates the transformation to an XSLT page built specifically for the job.
The XSLT adheres to the same XML document structure that the page handler did when it built the document. The transformation extracts the generic data from the XML document, massages it, applies layout and formatting rules, inserts any necessary script, and delivers the finished product to the controller.
The controller delivers the final document to the client.

Listing 6-1 shows an implementation of the controller design pattern using ASPs.

Listing 6-1 controller.asp: a simple implementation of the controller ASP page.

 <% // Get the view argument view   = Request.QueryString("view") base = Request.ServerVariables("SERVER_NAME")+
Replace(Request.ServerVariables("URL"),"controller.asp","") if Request.ServerVariables("HTTPS") = "ON" then base = "https://"+base else base = "http://"+base end if xmlurl = base+view+".asp?" arguments = "" // Parse additional arguments For Each item in Request.QueryString if arguments <> "" then arguments = arguments+"&" itemvalue = Request.QueryString(item) arguments = arguments+item+"="+itemvalue Next // Append the argument string to the xmlurl xmlurl = xmlurl+arguments // Contstruct a URL to the appropriate skin // This implementation uses only the Internet Explorer 5.0 skin // Other skins could be used based on the browser type if Request.QueryString("skin") <> "" then skin = Request.QueryString("skin") else skin = "ie5" end if xslurl = base+"xslt/"+skin+".xsl" // Load the XML // A production implementation should use the multi-threaded 
version of the DomDocument. error = false Set source = Server.CreateObject("MSXML2.DOMDocument") source.async = false tmp = source.setProperty("ServerHTTPRequest", true) source.load(xmlurl) Set e = source.parseError if e.errorCode <> 0 then Response.write(e.reason) if e.line > 0 Then Response.write(e.line) Response.write(" ") Response.write(e.linepos) Response.write(" ") Response.write(e.srcText) end if error = true end if // Load the XSLT Set style = Server.CreateObject("MSXML2.DOMDocument") style.async = false tmp = style.setProperty("ServerHTTPRequest", true) style.load(xslurl) Set e = style.parseError if e.errorCode <> 0 Then Response.write(e.reason) if e.line > 0 Then Response.write(e.line) Response.write(" ") Response.write(e.linepos) Response.write(" ") Response.write(e.srcText) end if error = true end if if error = false Then xmlresult = source.transformNode(style) end if Response.write(xmlresult)  %>

This approach to Web site design can also be applied to UI design for Web applications. It offers a number of benefits. Splitting page rendering into isolated construction and formatting tasks enables parallel development activity and shorter development timelines. Furthermore, these distinct activities can be assigned to specialists. Content authors have greater knowledge of the intricacies of the application's business logic and the various ways used to pull information from the back-end. Layout specialists can focus on the aesthetics of the UI, worrying less about where the information comes from and more about how it should be presented.

This approach is also extensible. The controller can be augmented to decorate or filter XML content based on a user's browser or role within the application. New presentation skins, or transformations, can be plugged into the environment without rewriting every page. This approach also discourages monolithic page design. By promoting the segregation of content from presentation, the controller pattern makes an application easier to maintain over the long run.

The User Interface Schema

Team members need to work together to make a project succeed. In this case content developers and layout designers can communicate in a common, well-defined language by using XML and XSLT to implement a controller-based UI. This language, or schema, defines the documents that flow through the application. The schema acts as a blueprint for content developers when they begin building pages as well as a specification the presentation group uses when constructing their XSLT. The schema is used to validate the documents in the application, and it should address common UI aspects such as layout, navigation, input controls, user actions, and security. Once the schema is finalized, the two groups can begin working independently, so get this out of the way first.

Defining your UI this way forces your team to think abstractly about what they're trying to show in the application. This process yields immediate returns. Presentation specialists will see ways to interpret the UI XML documents in more interesting ways. System architects will uncover newer uses for XML within the program. And once you've defined your project's UI schema, content developers can begin building conformant documents before the presentation rules are even implemented!

Two Approaches to User Interface Schemas

The goal of your UI schema is to define an XML document model that can be easily transformed into UI elements within your application. The nature of this schema depends on many factors. How broad is your application? How many different business entities are involved? What types of clients will be using the system? Will your application need to support a wide range of browsers with different capabilities (such as an Internet application) or just a single browser (an intranet application)?

Generally speaking, your UI schema can follow two broad categories. The schema can be presentation based, in which the elements are associated with UI functions instead of the type of data shown. The XSLTs for this type of schema translate the generic UI controls into browser-specific documents. Conversely, the schema can be business object-based. XML documents under this paradigm model business entities and contexts instead of generic forms. More XSLT work is required in this scenario, as it is responsible for creating the entire UI.

Presentation-Based User Interfaces

Presentation-based UI documents are easiest for traditional HTML developers to understand. Presentation-oriented schemas define generic document structures that all pages in the system must follow. Note that the HTML specification given here is only one example of a presentation-based schema.

Advantages to using a presentation-based UI schema include

A shorter learning curve. The approach is similar to HTML and is easy for HTML developers to understand.
A small number of required transformations. This schema requires a transformation template for each piece of the generic content model. New transformations are unnecessary even if the number of pages in the system grows.
More consistent-looking pages. Associating the schema and transformations with document structure will enforce consistency among the pages in your application.

Disadvantages to this approach include:

Lost meta-information about the underlying data in the page. The schema does not care what kind of data is being displayed as long as it has a valid document structure.
Difficulty in defining highly dynamic pages. Some pages in your application will require a lot of client-side scripting to handle user interaction. This can be difficult to achieve without hard coding the scripts directly in the pages.

Therefore, use a presentation-based UI schema if the number of different business entities or the number of pages in your application is large. A presentation-based schema is durable, scaleable, and evenly divides UI responsibilities between content developers and layout designers.

To show you how this type of schema can be useful, Listing 6-2 illustrates what the XML for a specific person might look like under a presentation-based schema.

Listing 6-2 An example of a presentation-based XML document.

 <document> <header> <title>Person Detail</title> <icon>person.gif</icon> <section> <header> <title>William Jones</title> </header> <view> <properties> <property description="First Name">William</property>  <property description="Last Name">Jones</property>  <property description="Address">200 Irving Street</property>  <property description="City">Cambridge</property>  <property description="State">MA</property>  <property description="Zip Code">02138</property> </properties> </view> </section> </document>

This document looks similar to an HTML document, although XML has no hard-coded presentation rules. Instead the layout designer can use a number of clues when rendering this page. Still, not much meta-information describes the nature of the data that the document contains.

Business Object-Based User Interfaces

The second category of UIs is a business object-centric approach to UI XML documents. In this case the underlying XML documents represent business entities instead of document structures. Here XML documents describe the type of data being shown (for example, CD, employee, or automobile) on the page and the context of the page (for example, detail, edit, or creation). The XSLT developer must create transformations that build unique documents for every type and context combination allowed by the system.

Advantages to using an object-based UI schema include

More specialized pages. If certain object contexts in your application call for highly dynamic and custom pages, an object-based approach might be the way to go.
Preserved metadata. XML documents that abide by a business object-oriented schema provide information about what the data is instead of how to display it. Metadata can be useful if your application makes heavy use of it on the client-side.

Some of the disadvantages to an object-based approach are:

It does not scale well as the number of business entities or their contexts grow. Multiple transformation templates covering a variety of contexts must be implemented whenever a new business entity is introduced.
Consistency in look and feel is more difficult to achieve. Highly-specialized pages might thwart valiant efforts to install a global look and feel.
Global changes are more difficult. Presentation rules might be scattered across a number of different object transformation templates. These should be localized if possible.
This approach places a heavy burden on the XSLT author.

Accounting for the advantages and disadvantages, use an object-based UI schema when your application has few business entities with highly specialized UI requirements. This approach will help you isolate dynamic content into browser-specific XSLTs. Client-side scripts are generated by the XSLTs instead of by the content developers.

The following code details what a business object-based XML document might look like.

 <person context="detail"> <firstName>William</firstName> <lastName>Jones</lastName> <address>200 Irving Street</address> <city>Cambridge</city> <state>MA</state> <zip>02138</zip> </person>

This XML document is noticeably different in structure from the presentation-based document shown previously. The XML elements in this file only relay information about the type of data viewed and the context where it is utilized. The XSLT author is responsible for packaging this information into UI elements. The XSLT might also need to request additional XML data (such as the person's company information) via a separate HTTP request.

The User Interface Schema in This Chapter

At this point we will adopt a presentation-oriented XML schema for later examples. The examples are not too complex and the time-saving benefits that a presentation-based schema provides outweigh any concerns we might have about dynamic content. For your application, however, you should pick the UI schema approach that works best in your environment. You might even decide to implement a combination of the two approaches, in which specific object-based XML documents are transformed into generic presentation-based XML documents.