Techniques, Tricks and Traps in ColdFusion/WAP Development

Let's get down to brass tacks and talk about some of the real challenging issues that may rear their ugly heads in your first forays into WAP programming in ColdFusion. If you're ready to start programming, you can just go to work with the things we've described so far. You'll have a great head start given that there is no documentation in the Allaire manuals on WML development, especially the specifics of doing it with ColdFusion. The rest of this book gives you a great resource for working with WML in general.

 

But once you begin coding WML applications, you learn that there's really a lot more to doing WML programming than just knowing WML and ColdFusion tags. As we saw in the last section, because ColdFusion was originally designed for the development of "traditional" web applications, some Studio features may not work as you would expect.

 

The same is true with respect to some ColdFusion programming features. You'll inevitably trip over them, and you can get around most of these problems with the right solutions. They're just not always obvious, so you need to know what to look out for. Some may feel that this section reads like a reference. If you prefer, you can use it that way. If you want to avoid the problems up front, read on.

 

The topics include:

 

q         Error handling

q         ColdFusion environment configuration

q         Browser detection and redirection

q         Form processing

 

We also conclude with a handful of miscellaneous concerns that don't fit into any category but are just as important (potential problems using <CFABORT>, processing URL parameters, and more).

 

Along the way, we include solutions to a handful of potential errors that will prevent your code from working, even if the code seems correct.

Error Handling

Let's start with the first big challenge – viewing errors themselves. Here's one rule that you must always remember:

 

In your first attempts to use ColdFusion-driven WML templates, one major challenge is simply being able to discern the cause of the error. When your code has an error in the ColdFusion code itself, ColdFusion will indeed generate an error message that is sent to the browser for display. Sadly, ColdFusion formats the message in HTML. That's always been fine (indeed, useful), until WML development came along. The problem is that a WML browser will choke on an HTML error message as being malformed WML.

 

Not only can you not see the error that is causing a problem – it might instead appear that the problem is with your code coming to the browser, or with the browser or network.

 

The problem is exacerbated by the fact that most WML browsers don't give you much assistance in the way of showing you what has caused an error. Some try, but most leave a lot to be desired. We'll most likely have to wait for a new generation of WAP browsers before we see a solution to that particular problem – but in the mean time, how do we manage?

Trapping and Reporting Errors with CFERROR

There is a way to make most ColdFusion template errors become more usefully reported to you and your users. You can change some (but only some) of the ColdFusion errors that arise to be viewable in WML, so that you can see them in the browser, using a feature of the <CFERROR> tag that is new in version 4.5 of ColdFusion.

 

First let me explain the overall use of the feature, which has been around in previous versions.

 

<CFERROR> has always been available to allow you to direct ColdFusion to send your users to a different – customized – error display page when an error occurred. Again, the default is to just show a plain error to the user, but <CFERROR>, when used, allowed you to modify the error display page to use your site's background colors and images, and even offer contact information for your help desk or support staff.

 

Unfortunately, prior to 4.5 this custom error page did not allow you to do any ColdFusion processing. It offered a pre-defined set of error information variables indicating the error detail, time, browser address, and so on which you could show to the user. But you couldn't do much else on the page: you couldn't use <CFMAIL> to send the message to your administrator; you couldn't use <CFQUERY> to log the error.

 

Worse for WML developers, there is no way with this approach to have the error page send the user a WML formatted message. Even though you can control what's sent to the user, it's still sent as HTML by default, and there's currently no way to change that. And since you can't put the <CFCONTENT> (or any other CF) tag on the page, you can't override that default. Things would seem hopeless.

 

In ColdFusion 4.5, however, Allaire has extended <CFERROR> with a new TYPE="exception"
option. When there is an execution error, this feature can direct the user to a page with the full power and capability of ColdFusion. As such, a WML error page with the CFCONTENT tag would be a good thing to create.

 

Here is an example of a custom WML error page that could work in version 4.5:

 

 

 

Now, this is not perfect. The <CFERROR TYPE="execution"> tag doesn't catch every error occurring in ColdFusion (it doesn't catch errors due to CF compilation, or "file not found" errors, to name just
a couple).

 

Also, the detail of the error message itself, available in the variable CFERROR.DIAGNOSTICS, is itself formatted as HTML. The best we can do is use the XMLFORMAT function (or the HTMLEDITFORMAT function prior to 4.5) to cause the HTML to be rendered appropriately, such as with &GT; and &LT; tags. Using either function is a kludge, since some WML browsers still may not support all the code that may be sent, but it's the best we can do.

 

Finally, another thing to consider is that if you don't limit what's sent to the browser in the error message displayed, it could send so much information to the browser as to choke it.

 

Still, doing something so that most errors are properly formatted is better than doing nothing and having none of them properly formatted.

 

And, of course, this error handling solution won't help if the problem isn't a ColdFusion error but instead a problem of badly formatted WML. In that case, the browser will reject it as well. How to tell the difference? It does get thorny. Just learn how to use all available error diagnostic tools, and test, test, test.

 

The way to use the error page shown above is to create it as a file called (for example) wml_error.cfm, saving it in your directory of WML files. This is one reason why it's a good idea to keep all your WML files separately in one directory – we don't want this page to be used when HTML files get an error. (We'll see shortly how to set up browser detection to direct pages appropriately)

 

To call upon this newly created error page, we'd want to direct our templates to execute the following tag at their initiation: