|By Serge Ohotin, Paul Elisii||
|August 31, 2001 12:00 AM EDT||
While developing an application in Wireless Markup Language (WML) for Wireless Application Protocol (WAP) devices, I realized just how many different types of wireless devices exist globally and how different the protocols and languages have to be from device to device. In a previous article, "ColdFusion in the Palm of Your Hand" (CFDJ, Vol. 2, issue 4), I showed how ColdFusion applications can be written and deployed to a wireless Palm VII. In this article I compare and contrast writing that same application in WML for WAP devices.
Taking the Palm VII application and rewriting it in WML for WAP devices wouldn't be overly difficult, but what about all the other devices and protocols such as HDML and XHTML? Rewriting the application for all those various devices and then supporting all the code bases would be quite overwhelming. Ideally, if there was a single markup language that supported all wireless devices, you could just support that single language. However, with the proliferation of more and more protocols and languages it's not very realistic.
There's no questioning the fact that supporting all these wireless devices is important. A recent IDC Report estimates that by 2002 (see Figure 1) there will be more wireless devices capable of browsing the Internet than wired browsers and by 2004 it will be close to double. Worldwide, the ability to support wireless devices will be critical where wireless device penetration will far exceed personal computer penetration.
With a proliferation of wireless devices accessing the Internet, applications will need to support these devices just as applications must support various browser versions. You wouldn't dream of developing an Internet application that supports only IE or Netscape, so we should be writing applications that support both HTML browsers and wireless devices. Even though it's not realistic to support a single markup language for all wireless devices, there is a way for you to have a single application that does this. It can be accomplished using XML and XSLT.
This article illustrates how to write a single application that uses XSLT to output its data to HTML for browser access and WML for wireless phone access. The generated XML content will be transformed into each of the desired markup languages (see Figure 2).
The XSLT process takes both an XML and an XSL document as input and, using an XSLT processor, transforms the XML into a different form of XML, HTML, WML, or any other desired output.
The XSL document specifies the rules regarding how the XML is translated. An XSL document is similar to a Cascading Style Sheet (CSS), but much more powerful. XSL is really a language specification in which you can use loops and so forth to translate XML data.
If your application creates HTML as output, like most traditional applications, you can use CSS to take an HTML document and specify how that HTML will be presented. However, if your application creates XML as output, you have many more options. You can apply a CSS to the XML to present the data; you can use XSLT to transform the output to other XML, HTML, WML, etc.; or you can use XSLT to transform the output into XSL-FO (XSL-Formatting Objects), which allows you to present the data in additional formats such as a PDF.
Basics of XSL (XSLT and XPath)
Two of the main components that make up the language elements of XSL include XML Path Language (XPath) and XSLT. Most XSL documents contain elements of XPath and XSLT to transform XML documents.
To actually execute the transformation an XSLT processor is required. This processor takes the XML and XSL and then parses to create the desired output. This process is standardized by the W3C and there are many good XSLT processors available on the Internet such as MSXML, Saxon, and Xalon. A list of XSLT processors can be found at www.wrc.org and can usually be freely downloaded. For the examples in this article we use the Saxon XSLT processor. It's Java-based, easy to use, and a complete implementation of the standard.
Within an XSL document you'll use both XPath and XSLT to translate XML.
XPath allows you to navigate within the XML document tree. For example, child::* will match all the children of a context node that's currently being processed. The XPath language also contains predicates (filters) and functions that can create very powerful capabilities of parsing XSL documents.
XSLT allows you to select and manipulate the data elements that you can use to navigate XPath. It allows you to create templates, specify output, and control the flow of processing in an XSL document. One example of an available function is the count() function, which could be used to parse through an XML document and output all the customer records that have at least two orders, for example:
There are entire books dedicated to XPath and XSLT. Two that were useful in the writing of this article were the XSLT Programmer's Reference by Michael Kay (author of the Saxon parser) and Professional XSL by Kurt Cagle, et al. Both books are published by Wrox Press Ltd.
Sample Application - Contact Manager Lookup
In this article I review a contact management application that queries a database for a list of contacts that match the desired query request.
The two main controlling ColdFusion files in the application consist of contacts_form.cfm and contacts_result.cfm, which can be found on the CFDJ Web site, www.sys-con.com/coldfusion/sourcec.cfm. In addition, two XML stylesheets are used that transform the XML result set to HTML and WML - wddx_to_html.xsl and wddx_to_wml.xsl, respectively.
For ease of discussion, I created a fairly simple application that takes some input from the user, performs a query, returns that result to XML, and then transforms the XML into the appropriate output for the desired device.
The contacts_form.cfm source code contains an HTML form for HTML devices and a WML form for WAP mobile devices. The <cfif> tag first checks to see if this is a device that supports WML. If it does, the WML form is built, otherwise the HTML form is built. First, the HTML form will be examined along with the output, then after a brief overview of WML, the WML form and subsequent output will be reviewed.
We could have used XSLT to transform the user input forms from XML to the appropriate HTML or WML, but since the forms are statically built and quite simple, it didn't make sense to do so. This is something that you may want to consider in more complex applications.
Support for HTML Devices
The HTML form that's built to query the user for input is quite basic. As the code in contacts_form.cfm illustrates, the form uses a standard HTML form and Input tag to gather user input, then passes that input as a form field to the contacts_result.cfm page.
Displaying the results of the query is where things get much more interesting. To display the matching contacts from the database, the single ColdFusion file, contacts_result.cfm, is used to query the database, convert the ColdFusion query to XML, and then transform that XML into either WML or HTML using an XSLT processor.
The actual process of transforming the XML is completed with a series of Java calls from lines 34-56 of contacts_result.cfm. The <CFOBJECT> tag instantiates the Java object and then the methods are called to perform the actual transformation. All the Java code was embedded directly into the ColdFusion page in this example to illustrate how this can be done completely with ColdFusion. We've also implemented this as a pure Java Web service that can be run from JRun or another Java application server and called from ColdFusion.
The first section of the code checks to see if it's a WML device that's requesting the page. If it's not, the code defaults to HTML. The XSL and content type for HTML is set up and the form field, contactName, is prepared for the query statement.
Next the query is executed and the results are stored in the contacts ColdFusion query object, which is then converted to WDDX via the simple ColdFusion tag, <cfwddx>. Since the XSLT processors will operate on any compliant XML code, I decided to go from WDDX directly into HTML and WML as opposed to going into a more pure form of XML first.
Traditionally, XML output is in the following form of name and value pairs.
This makes writing the XSL stylesheet quite straightforward and easy. However, WDDX organizes its data a bit differently, which makes writing the XSL stylesheet a bit more complicated.
Figure 3 displays the WDDX that we're converting. As you can see, each field node contains all the values in the result set, then the next field, and so on.
When we output the results we want them grouped by each individual record, so we create a looping mechanism in the XSL stylesheet code that regroups the fields in each record set. It'll be very useful to refer back to this WDDX as we examine the XSL stylesheet code.
Also, in writing the XSL stylesheet it was important to stay generic and not refer to any specific fields within the WDDX packet. By creating it so that it can generically take WDDX and convert it to WML and HTML, I was able to add or remove fields from my query and not have to change the corresponding XSL stylesheets. The trade-off is that you can't be as specific with some of the formatting. In most real-world applications you'll have to be more specific about the XSL to get the formatting you're looking for. The WML example XSL document illustrates this.
The source code that illustrates the XPath and XSLT code used to transform the WDDX packet into HTML is found in the wddx_to_html.xsl file (also found on the CFDJ Web site). The XSL stylesheets for HTML and WML are very similar - they both parse through the WDDX packet in the same way. The differences are in how they output HTML- and WML-specific content.
The first template in the XSL (lines 5-13) gets processed on the child node of the root. In the case of the WDDX packet, this processes the <data> section. Since there's only one <data> section in the WDDX packet, this gets processed only one time. This is where the HTML <body> and <table> tags are created and where a call to process the other templates is made.
The first template processed is template match="recordset". This template parses through the field nodes creating the HTML content. The first challenge in parsing through the WDDX packet is to create a looping mechanism that loops from one to the number of rows in the packet. A simple way to accomplish this is to loop through the child nodes of the first child record of <recordset>, see the following:
This looping construct loops through the data so we can extract the values for each of the data columns for the first row of data, the second, and so on.
Within the loop for each row of data in our WDDX packet we first get the value-of position() and store it in a variable. Then we begin our <tr> since we'll have one row in our table for each row of data in the WDDX packet. We have a second loop that loops through each column of data and then end the </tr>.
Within the second loop we take the $row variable and pass it into a third template called field that outputs the actual data to HTML. In our example, this template gets called 14 times (two rows of data with seven columns).
The field template (<xsl:template name="field">) is where the actual data elements are output into the HTML stream. The child node of the <field> node in the WDDX packet is the <string> node, which in our case contains the data that outputs the particular column and row it's called with. As we'll see in the WML example, special formatting will be performed in this template depending on which column is being processed.
The HTML version of the output is displayed in Figure 4. This is basic output to illustrate the basic concept of transforming XML into HTML.
A nice things about creating the XSL generically is that simply changing the query to add a fax number, for example, will change the output without changing any of the XSL code.
Support for WAP Devices
Before discussing the WML code in this sample application, I'll present a brief overview of WML.
WAP is a protocol for developing wireless applications. Its two main components are WML and WMLScript. They're similar in concept to HTML and Java-Script, but with some key syntactical and functional differences.
Two great sources for information and tutorials on WAP and WML are www.wapforum.org and www.wap.net. The basic architecture of WAP consists of a wireless client device (phone or PDA) that communicates via a wireless communication protocol to a WAP gateway. That WAP gateway then uses protocol adapters and compilers to communicate with a Web server, which communicates with an application server (in our case ColdFusion) (see Figure 5).
As a variation on this theme application servers that are coming onto the market have a built-in WAP gateway as part of their single-bundled product.
WML and WMLScript
WML and WMLScript are the languages used for WAP applications. WML, a form of XML, instructs wireless devices on how to display content. WML pages operate as cards in a deck, and a single page is referred to as a deck. Each card in the deck corresponds to a single screen on your phone. You can actually perform an HREF call from one card to another within a deck to navigate the client through your application.
The following is a simple example of a WML application:
<?xml version="1.0" encoding="utf-
<!DOCTYPE wml PUBLIC "-
//WAPFORUM//DTD WML 1.1//EN"
Hello Wireless World!
Many tags within WML are unique and specific to the language; however, other HTML and WML tags are the same. You have to be cautious, however, because not all devices that support WAP support all the tags available.
A great reference on WML and WMLScript can be found at http://developer.openwave.com/resources/index.html. In addition, you can also download the Openwave SDK, which allows you to test your WAP applications without owning a wireless device. It can be downloaded from http://developer.openwave.com/download/index.html.
The SDK installs pretty easily and allows you to download a wide variety of phone configurations/skins that emulate different WAP-capable phones. I downloaded the Mitsubishi T250 skin, which is the exact WAP phone that I'm currently using.
WAP Version of the Application
From the WAP emulator I can enter the URL (localhost or on the Web) just like a browser, and I can run the application just like it would run on a the actual WAP device. Running the exact same contacts_form.cfm page that was run from the browser produces the result shown in Figure 6.
On WAP-capable phones the actions that can be executed are usually on the upper-left and right-hand sides of the phone with corresponding keys. On the Mitsubishi phone the two buttons on the left- and right-hand sides of the Menu button control the actions.
To run the application via the phone emulator use your mouse to click on the corresponding keys, spelling out your words on the keyboard (much easier!).
The application functionally works the same way it did on the browser. I can enter the last name or company name that I'm searching for on the form, then click the left soft-key button to execute the Find action. That action executes a new page to display the results.
The output on the WAP device doesn't use a table and is formatted a bit differently. I decided to make the company name bold and to build in the ability to scroll the results by using the Next action on the phone. As you can see in Figures 7 and 8, the first page is returned and hitting Next displays the subsequent contacts by scrolling through the individual cards in the deck.
The XSL code for the WML version is contained in the wddx_to_wml.xsl file (see the CFDJ Web site). The structure and flow of the XSL for the WML output is very similar to the HTML version. Both parse through the WDDX packet the same way.
The first difference you'll notice is that the document type is different. The document type allows the WAP device to recognize this as WML output.
For the main document tag we use <wml> instead of <html>, and then for each record output we create a new card instead of a new row in our HTML table. To create the <card> tag with additional and dynamic elements, we use the XSLT <xsl:element> tag that starts on line 16 and continues to line 32. Each card in a WML deck must have a unique name, so the card is created as a combination of "contact" and the current position() being processed, which produces the following output.
Now the remainder of the card is built. Each column in the current contact is processed by the same field template that was used in the HTML XSL. The XSL used for the WML is more specific with manipulating the data elements. For example, the company name is bolded by using an <xsl:choose> on the element name and then performing different formatting for each element. If the @name is COMPANY_NAME, I use the <strong> tag to make the output bold. If the the @name is either CITY or STATE_PROVINCE, we use the <xsl:text> tag to insert a blank space. With all other fields we just add a <br/> tag for a new line. The WML output produced is the following:
74 Pottstown Pike<br/>
Eagle PA 19408<br/><br/>
When we come back to the lines after the <xsl:for-each> tag loops through the columns, we'll add an action for this card. Again, we use the xsl:element tag from lines 26-31. We'll build a WML <do> accept action with a label of Next. When this action is processed, it executes an HREF to go to the next card in the deck. We have to identify which card we're going to, and in this case, it will be the next contact, contact2. On line 30 we concatenate "contact" to the current position()+1 to produce the following result:
<do type="accept" label="Next">
The <xsl:element> tags are then terminated. This produces the following tags to complete the card for contact1.
Support for wireless mobile devices will increase rapidly in the next two years, and the demand for applications that support these devices will increase accordingly. Wireless application support will soon become a natural part of all Internet applications, as it is in Netscape and IE browsers.
Using XSLT, applications can be built to support multiple devices and allow developers to quickly add support for additional devices without having to rewrite the application.
Technologies and Resources
All examples were built using ColdFusion 5.0. However, no explicit features of ColdFusion 5.0 were used. All the examples ran under other versions of ColdFusion without difficulty.
All examples were run using IIS 5.0. A modification had to be made to IIS to allow it to recognize WML devices. The following content type had to be added: text/vnd.wap.wml
The SDK was downloaded from http://developer.openwave.com/download/index.html and all examples were run with the Mitsubishi T250 configuration/skin.
Version 6.2.2 of the Saxon processor was downloaded from http://users.iclway.co.uk/mhkay/saxon. The class files were copied to a directory in the class path so they could be called from ColdFusion.
- Where Are RIA Technologies Headed in 2008?
- The Next Programming Models, RIAs and Composite Applications
- AJAX World RIA Conference & Expo Kicks Off in New York City
- Constructing an Application with Flash Forms from the Ground Up
- Building a Zip Code Proximity Search with ColdFusion
- Personal Branding Checklist
- CFEclipse: The Developer's IDE, Eclipse For ColdFusion
- Has the Technology Bounceback Begun?
- Adobe Flex 2: Advanced DataGrid
- i-Technology Viewpoint: We Need Not More Frameworks, But Better Programmers
- Web Services Using ColdFusion and Apache CXF
- Passing Parameters to Flex That Works