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.
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.
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.
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!
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 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
Disadvantages to this approach include:
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.
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
Some of the disadvantages to an object-based approach are:
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.
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.