|By Charlie Arehart||
|August 23, 2000 12:00 AM EDT||
It's fun developing wireless applications in ColdFusion, but if you don't solve several key challenges it'll be more painful than pleasant.
In this second part of a series, I'll focus on some common problems encountered by CF/WML developers.
In the last issue the focus was on getting you started: an introduction to WAP (the Wireless Access Protocol), the early state of wireless programming, how to get a simulator to begin testing code, resources for learning more about WAP and the markup language for WAP phones, WML (Wireless Markup Language).
I intentionally didn't focus on WML itself or on the details of the WAP architecture. These matters are best left to the many SDK documents, Web sites and the growing number of books on the subject.
In this issue I'll focus on matters not covered by those resources: the problems you'll typically encounter when getting started with wireless programming in conjunction with ColdFusion. There are indeed many challenges that would affect any WML developer. I'll touch on a couple of them, but the real focus is on the CF-specific challenges, as well as some tips and tricks for getting things to work when trouble strikes.
The Key to Doing WML in CF
Before discussing the common challenges, I ought to at least give you a bit of sample code to begin with in case this is your first time reading about WML. As mentioned in the last article, I don't want to repeat too much of what was covered by Ben Forta's intro to WML in his December 1999 article, "No Strings Attached" (Vol. 1, issue 6). Please see that for more introductory WML.
The bottom line is that all you need is a properly formatted CFCONTENT tag to indicate to the browser that the code you're building is WML rather than HTML (ColdFusion's default). This sets the MIME type of the page you're creating. Simply include this at the top of your program:
<CFCONTENT TYPE="text/vnd.wap.wml">That's not quite all you need. There's a set of basic "prologue" statements that must be specified at the top of any WML page, so the more complete definition of the beginning of a CF/WML page, as offered in a simple "Hello World" example, is:
<CFCONTENT TYPE="text/vnd.wap.wml"><?xml version="1.0"?>Notice that we've put the first two lines of code on the same line. Many WML developers have found that the ?xml declaration line should be coded without any carriage returns preceding it.
<!DOCTYPE wml PUBLIC"-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml">
From here you can use any CF code to generate any WML as needed by your application. Again, see other more general-interest WML resources for more about the WML you can use. And you can do this in any version of CF. This leads to a natural question often asked by new CF/WML developers: What version of ColdFusion allows WML programming?
When people notice that Allaire has highlighted new WML support in 4.5, they get the impression that WML can only be done in 4.5 of CF Server. In fact, the new support is really just extensions to CF Studio and HomeSite to support creating, editing and getting help on WML tags, and a new page wizard. We'll review those in a later article.
Any version of ColdFusion (Server and Studio) can support WML programming if you're coding the tags by hand, since all you need is that CFCONTENT tag at the top of the page.
The Inevitable Errors You'll Encounter
If you try this sample code, or when you begin doing more substantial code, you'll inevitably encounter errors. The challenge is determining if it's a CF error or a WML error, and even then what works in one phone may fail in another due to the incompatibilities of phones supporting WML in different ways (which is beyond the scope of this article). But there are some simple issues we can deal with.
Viewing the Code in the Right Browser
First of all, you can't expect to run the preceding code sample from within a browser like IE or Netscape (at least not the current versions). With the CFCONTENT tag in place, you can view the output of the page only in a browser that supports WML (phones or phone simulators, as discussed in the last article). If you try to view it in a normal browser, you'll likely receive a prompt to save the file being sent, since the browser doesn't know what to do with a file of the MIME type specified in the CFCONTENT tag.
Dealing with "Invalid Content" or "Syntax Errors"
Even when viewed on a real phone (or simulator), you'll encounter errors in your first forays into WML. There are a few things to keep in mind.
First, WML is case-sensitive. You must use lowercase for WML tags and attributes. Also, WML follows the rules of XML programming, so all tags must have a closing tag. Even a <p> tag must have a closing </p>, unlike in HTML, and tags like <br>, which have no closing tag, must be written as <br/>.
Note that you can't send HTML tags to a WML browser. (Well, that's not entirely true. Some WAP gateways can convert HTML to WML, but that's not universal and shouldn't be relied on.) If you send HTML to WML browsers, they'll generally "choke" on it. So be careful don't intermix HTML and WML. You really need to find some WML resources to learn more. For all their similarity, there are many significant differences between HTML and WML programming, and they're more than just differences in tag names.
Other problems could arise if you have an error in your CF code (causing CF to display an error message), or if you have server-side debugging information turned on, both of which generate HTML, as we'll discuss next.
Turn Off Server-Side Debugging
ColdFusion's HTML heritage can really get in the way when doing WML programming. When debugging is turned on in the Administrator, you normally see the debugging info at the bottom of any CF page. But that information is sent in HTML formatting to the browser, which is fine in a normal browser, but it's death to most WML browsers since they can't read HTML.
You don't need to turn off debugging in the Administrator. As of ColdFusion release 4, you have the option to turn off debugging with the following line of code:
<CFSETTING SHOWDEBUGOUTPUT="no">This will disable debugging until you turn it on again or until the currently running template ends. If you're running a release of ColdFusion prior to release 4, it's probably best to just turn off server-side debugging.
Why Can't I See ColdFusion Error Messages?
On a related matter, the same problem of CF's HTML heritage has to do with error message handling. When you get an error in CF, you normally see the CF error message display indicating the error and the page and line number of the code in error. But that error is also sent in HTML formatting to the browser, which chokes the WML browser.
This would seem a real dilemma. You can't see the error because the phone doesn't recognize it as valid WML. So how are you supposed to deal with it? Well, fortunately, Allaire has put in place error-handling components to improve the ability of the developer to control the error message display to the user.
You might think that CFERROR, and its ability to create a specially formatted error page, might come to the rescue. Unfortunately, the two older forms of CFERROR pages (type="request" and type="validation") send pure HTML (and an HTML MIME type), which you can't override. Since you can't put any CF tags on those error pages, you can't even add a CFCONTENT.
(This also means, of course, that you can't use CF's hidden field validation to do server-side form validation. The validation error page that it offers is also pure HTML and you can't override it.)
Perhaps Allaire will offer a solution to these dilemmas in the future. For now, if you have release 4.5, you can in many cases at least solve some of the first problem seeing CF error messages by taking advantage of the new CFERROR type="exception". This transfers control when an error occurs to a page that is allowed to do CF tags (an incredibly valuable new feature in and of itself), including a CFCONTENT tag. You can then format the error for display to the WML browser.
Formatting the Error Message Itself
You're not quite done, though. The CF error message itself, offered inside such a CFERROR page as the variable CFERROR.Diagnostics, will usually be HTML-formatted. This was fine when sending it for display to an HTML browser, but again it's a problem in WML. Fortunately, you can solve it by using a CF function to convert the HTML tags in the message into their corresponding display codes, such as &gt; for > and &lt; for <.
Allaire offers two solutions for this. In 4.5 there's an XmlFormat() function for just this purpose. In older releases you can use HtmlEditFormat(). It's not the perfect solution, as it'll simply cause any HTML tags in the error message to be displayed to the screen, but it's easier than trying to strip out the HTML tags.
This approach can also be used to format error messages displayed in a CFCATCH (using the "cfcatch.detail" variable).
You may want to create an application.cfm that sets the CFSETTING to disable debugging output (on a release 4 or above server) and sets a CFERROR type="exception" (on a release 4.5 or above server) to point to a template that can format the error message in WML.
Keep in mind that none of this CF error handling will help if the error in your page is due to badly formed WML. In this case you'd do well to have a simulator that allows you to see the actual WML being sent to the browser (most real phones won't provide access to that information).
Form Processing Works in Simulator, Fails in Real Phone
This is another thorny problem, and it's not generally CF-specific. Some background will help. When you test code in most simulators, you may be using a form of communication between the simulator and the Web server that's often called "http direct". There is direct communication between the simulator and the server.
This is fine, but real phones use a form of communication that goes from the phone to a gateway (usually within the phone company provider) that then communicates to the Web server on the phone user's behalf. (It acts as both a proxy and a translator, since what's really sent to real phones is an encoded form of WML to minimize data traffic.)
The problem with this scenario is that code that works fine in the "http direct" mode may fail when run on a real phone or in the simulator's gateway mode.
A perfect example of this is "form processing" by way of the "post" method. If the example in Listing 1 is submitted on a simulator, it will work, but on a real phone it may fail.
I don't have room here to explain the unique differences of form processing in WML versus HTML, but the example shows many of the significant features. Note that there's no "form" tag per se, and that the form data is gathered in one place (the input tag), stored in a variable on the phone ("stock") and passed to the server in yet another tag (<go>) when the user presses the "accept" button or equivalent. Very different from HTML! But note the powerful new formatting possibilities in the <input> tag. This allows only up to four alphanumeric characters.
The problem occurs when the page itself is submitted with method="post". In testing on a simulator in HTTP direct mode, this code works fine. In a real phone, however, which goes through a gateway, it will fail to submit. In the Phone.com simulator, using the "up.link" mode to go through a gateway, it fails with an error "500:internal server error". It seems the gateway is simply unable to make a "post" method call to the server.
And it doesn't seem to be restricted to CF Server (I tested the problem against an ASP program and got the same error). It may be restricted to Phone.com gateways, though I've heard it happened to users of Nokia phones and simulators.
The short-term solution is to change the method to "get". ColdFusion will receive the variables as "url." variables (in the example above, the "url.symbol"). Unlike in HTML browsers, this doesn't have the same problem of showing the user the form variables on the URL of the action page since phone users don't see the URLs of sites they're visiting (currently).
There is the security risk that on an SSL-enabled connection (called WTLS in the WAP world) the data passed on the URL isn't encrypted, so this isn't a solution that will work when passing userids and passwords, or credit cards if the goal is to encrypt that data. But that, too, is beyond the scope of this article.
That's All for Now
That's all the time (or rather, room) we have this month. Upcoming articles in this series will cover some other challenges (and solutions) regarding wireless development, such as doing browser detection to serve both HTML and WML browsers, handling sessions in an environment in which cookies aren't always supported, doing CFLOCATION (you have to use Web server root-relative paths, even to send to a file in the same directory), what to do when CFCONTENT simply doesn't work in your CF server, processing multivalued form field submissions, sending notifications and pushing messages to the phone (using COM objects), and the support in Studio for WML.
You can learn about WML and generic challenges as well as more about these CF challenges in the recently released book Professional WAP (Wrox Press). I have a chapter in the book on CF/WML programming. Other WML/WAP books will soon be in the market as well.
- 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?
- Cloud People: A Who's Who of Cloud Computing
- i-Technology Viewpoint: We Need Not More Frameworks, But Better Programmers
- Adobe Flex 2: Advanced DataGrid
- Web Services Using ColdFusion and Apache CXF