Tom Mollerus' Weblog

An interesting question came up in conversation during my ride to work this morning: can Google Analytics track users if a site's registration process consists of AJAX calls instead of multiple page requests?

As a follow-up from my earlier posting on tabbed dialog boxes using ColdFusion 8's new cflayout and cflayoutarea tags, I'll explain how you can also use those same tags to create dialog boxes with expandable/collapsible trees or icon lists in the left-hand pane and forms in the right-hand pane. These kinds of interfaces will be readily recognizable by users since they're almost exactly the same as you'd find in a desktop application.

With ColdFusion 8's new cflayout and cflayoutarea tags, you can now create tabbed dialog boxes like you'd find in any desktop application, complete with Save, Cancel, and Apply buttons. Users will instantly be familar with the interface.

In a previous post, I noted Ashwin Matthew's technique of calling CF from a command-line interface with the use of cURL. This idea got me thinking. Using cURL to pass URL parameters to a script is well and good if you are manually typing the calls, but... what if you want to automate the process and and pass dynamic data whenever a certain event happens on your server?

For instance, I often write PHP scripts to automatically handle responses to certain emails that have been sent in to our company. Emails containing unsubscribe requests are processed so that the corresponding email is removed from our newsletter list; support requests get an autoresponse and are passed on to certain personnel; and I've even written a script for a web-based project management site that redistributed any email it received to a dynamic list of project members. All of these tasks happened automatically, as soon as our mail server received an email. Now I've figured out how to do the same thing with ColdFusion-- and this will work without event gateways and even if your mail server is separate from your web server.

A note to French waiters on how to correctly translate the menu item "petite friture" for your English-speaking customers: it's not as helpful to say "fried fish" as it is to say "fried fishes", or perhaps even "little fried fishies".

"Petite friture". Click for a larger view.

I ordered this dish during a trip in France this May for our 10th wedding anniversary. While petite friture doesn't exactly look appetizing, at least to me, I have to admit that it didn't taste so bad. Nor did any of our waitstaff fit the stereotype of the rude French waiter-- they were all very friendly, and considerably patient with my poor attempts to converse in French.

If you're lucky enough to be performing a major site upgrade by switching to a new server, then your migration path is pretty simple: develop on the new server, test until the new application is stable, and then switch over to the new IP address. But if you don't have the luxury of a new server, you're probably going to have some downtime on the site while you upgrade to new code. So what code do you show your users in the meantime?

Since there could always be application-level problems during an upgrade (perhaps you're altering database tables, changing session defaults, or site-wide layouts), you probably want to stick with a static HTML page to show your message. So what I do is create a redirect in the application code, practically in the first few lines, which sends all users to a static HTML page. That page tells the user that the site us undergoing planned maintenance and will be back up shortly. The page also contains a 10-minute refresh back to the application. If you are still upgrading or testing and have the application redirect in place, users will be returned to the static page for another 10 minutes; if you're done upgrading and testing and have removed the application redirect, users will see your new, upgraded application.