Tom Mollerus' Weblog

For those of you in the Boston area, you'll really enjoy the Boston ColdFusion User Group's meeting tonight at Adobe's offices in Newton. Luis Majano will be presenting his ColdBox framework-- it's a great, easy way to get introduced to OOP programming. Make sure to come!

http://www.bostoncfug.org/index.cfm?event=showMeeting&meetingID=CA04FA80-D61B-FA8C-8A343B03A53B5745

I'm pleased to say that Brian Rinaldi recently offered for me to be his co-manager for the Boston Coldfusion User Group, and I happily (and immediately) accepted. I'll be helping Brian with some of the management activities that he's always wanted to do but hasn't had time for, and I hope that it gives me the chance to meet more people in the community and to spread the word about ColdFusion to new users who are interested in seeing what it's about.

For those of you in the Boston area, we'd love to see you at the meetings. We've got some great ones lined up in the near future!

I visited the Adobe MAX 2008 site after reading Ben Forta's blog post about the ColdFusion "unconference" behind held during MAX.

After noticing a little animation in the very-grayed-out background, I clicked to see if anything would happen. It turns out that there are three adjacent mini-worlds, each with its own short puzzle for you to solve, which lead to one easter egg apiece. They're pretty fun. Follow the link above to MAX if you want to see for yourself, or read more if you want to know the easter eggs that I found.

If you're in the Boston area and didn't make it to the ColdFusion User's Group meeting tonight on unit testing with MXUnit, you missed a good time. Marc Esher and Bill Shelton gave us an intro to unit testing, and a few of us went out afterwards to Dunn-Gaherin's to toss a few back with our visiting ColdFusion evangelist, Adam Lehman. Adam kindly said a few words about Adobe's current efforts with CF, and also raffled off a copy of ColdFusion Server.

Be sure to make it to the next meeting, when yours truly will be presenting on version-tracking your code with Subversion. I'll be raffling off a free copy of Subversion. ;)

P.S. So that no one misses the joke, then shows up expecting a chance at free software and gets angry at me: I'm kidding. Subversion is already a free download.

I made yet another update to EmailParse.CFC last week while I was working in the code for other reasons: I've added spam lookup on the sender's IP address courtesy of SpamHaus.org.

I've posted an update and a fix to my EmailParse.CFC today:

• The quoted-printable parsing for text and html body parts has been corrected. When you use EmailParse.CFC to forward an email, you can't tell CF that a mailpart is encoded with quoted-printable or Base-64. So, these mailparts need to be converted back to text in order to forward them correctly.
  
  
• The parsing mechanism has been updated so that the values of the "Received" header, which often is often repeated several times in one email head, are aggregated in one property of the component. Previously, each instance of the Received header would overwrite the previous one, leaving only the last one for you to work with once the parsing was done.

You can read more about my email-parsing code for ColdFusion in the EmailParse.CFC Project area.

In my previous post, I wrote about the trouble I had trying to install the CF 8.0.1 Updater for Linux. Thanks to a few good tips from Brian and Todd, I now know how to install the Updater without a problem-- but I think that I might as well post the solution since Adobe doesn't seem to realize that it may not be obvious to everyone.

Because the Updater has a .zip extension, I took it for a zip file. Without any other direction from Adobe, that seems like a reasonable course of action to me. But when you try to unzip the updater, you get errors. The solution is pretty simple: just download the updater file, change its extension from .sh to .bin, make it executable, and then call it directly:

# wget http://download.macromedia.com/pub/coldfusion/updates/801/coldfusion-801-lin_updater.zip
# mv coldfusion-801-lin_updater.zip coldfusion-801-lin_updater.bin
# chmod 755 coldfusion-801-lin_updater.bin
# ./coldfusion-801-lin_updater.bin

That will start the Updater quite nicely. Oh, and one other thing-- when the Updater finished and I went to view my site, I got a 500 error from the webserver. A simple stop-and-start of the coldfusion_8 service did the trick:

# service coldfusion_8 stop
Stopping ColdFusion 8, please wait
Stopping coldfusion server..stopped
ColdFusion 8 has been stopped
# service coldfusion_8 start
Starting ColdFusion 8...
The ColdFusion 8 server is starting up and will be available shortly.
======================================================================
ColdFusion 8 has been started.
ColdFusion 8 will write logs to /opt/coldfusion8/logs/cfserver.log
======================================================================
#

I've written in to Adobe Support about it, but I want to know if anyone else has experienced the same problem that I have with the ColdFusion 8 Updater. Whenever I download the Linux version of the Updater and try to unzip it, I see the following issue:

[root@elmcedar src]# unzip coldfusion-801-lin_updater.zip
Archive:  coldfusion-801-lin_updater.zip
warning [coldfusion-801-lin_updater.zip]:  69730304 extra bytes at beginning or within zipfile
  (attempting to process anyway)
 extracting: Z_/installers/LiveCycleDataservice/flex-for-cf.zip  
 extracting: Z_/installers/JNBridge/JNBridge.jar  
   ...

When I download the same file to a Windows machine, I'm told that the archive is corrupt and I don't see any files. Has anyone else experienced a similar problem, or has anyone else successfully unzipped and installed the Updater for Linux?

I want to share the news that there's now a demo available for Webmail, my ColdFusion web-based email client. Oh-- and as always, I'll make a free copy available to anyone who can make a translation file available in their language. I still need German, Portuguese, and many Oriental languages.

I need to create a page that takes a structure of members and displays it in random order on the page (kind of an ever-changing "here are the latest members to sign up on our site" table). I needed to work with a struct because 1) it's what our CFC was built to return, and 2) the member data had a nested hierarchy that would have been impossible to output easily if it were in a query. While Googling on randomization, I came across Ben Nadel's post yesterday on randomly-ordered lists. He makes an interesting comparison between different methods of sorting: by sorting a struct (fast but doesn't allow duplicates), random append/prepend from one list to another (slow), multiple swapping of items in an array (fast, but perhaps not very random), and random selection from one list into another (extremely slow). So it occurred to me that with a bit more thought about the sorting algorithm, I should be able to build on Ben's work to create a randomization function that was speedy, handled duplicates, and could return a random list (or list of keys) when passed a structure, array, query, or list.

I just found a "gotcha" with using forms that are spread across several tabs in a cflayout area. The form would render properly in all browsers, the tabs worked just fine, and my "Save" and "Apply" buttons submitted properly. Everything worked well, except whenever I submitted the form using Firefox my changes wouldn't be saved. In IE, however, the changes were kept. I checked out the problem in Safari 3, and the problem existed in that browser as well. (I'm referring to a Windows environment, by the way-- I don't know if this circumstance would occur on a Mac, although I tend to think it would.)

So the first thing I did to solve the problem was pretty revealing. I used cfdump to view the contents of the FORM scope after the form was submitted; in IE, obviously, all of the form data was being submitted, but in FireFox, none of it was being passed to the server. Why would this be?

I've been working with ColdFusion ever since version 4.0, but of course every once in a light bulb goes on over my head and I realize how I've completely misunderstood something. Like this.mappings in Application.cfc.

I have to admit that I had stopped trying to use this.mappings because I could never get it to work. I would create a mapping in the fashion that the docs told me to:

<cfset this.mappings['myMapping'] = "/path/to/my/folder" />

And then I'd try to refer to my mapping name in my code, as I figured I should:

<cfinclude template="/myMapping/myFile.cfm" />

But it never worked. The server would just throw an error and tell me that the mapping didn't exist.

But tonight it dawned on me, and I wanted to share the epiphany so that you can either solve the mystery, too (if you also could never figure it out) or have a good chuckle at my expense (if you can't fathom why I ever got something so simple wrong in the first place). You don't refer to the mapping name in your file path... you refer to the this.mappings variable. Doh.

So the correct use is:

<cfinclude template="/#this.mappings['myMapping']#/myFile.cfm" />

Don't laugh too hard at me. I can only hope this revelation of my own foolishness will lift the wool from someone else's eyes.

I wanted to share this "gotcha" that I spent an hour on the other night: I was using <cfajaxproxy> to call a CFC that I had created as a proxy to another (the proxy CFC had methods which were accessible remotely, while the other CFC, stored in session, had public methods that woudn't have been accessible via AJAX. The final CFC accessed Java functionality. The proxy was really simple; it just took the exact same arguments as did the other CFC, and passed them on to the appropriate method call:

<cffunction name="setIndicator" access="remote" output="Yes" returntype="boolean">
        <cfargument name="cat" required="Yes" type="string">
        <cfargument name="indicator" required="Yes" type="boolean">
		
        <cfreturn SESSION.user.finalcfc.setIndicator(ARGUMENTS.cat, ARGUMENTS.indicator) />
</cffunction>

But every time I tried to call the proxy via AJAX, I received an error...

I'd like to get some language files translated for my ColdFusion-based webmail client, which reads POP accounts. If anyone would like to provide a translation of a language file for me, I'll give them a free copy of the Webmail application, which normally goes for $29.00. The language file consists of about 250 words and phrases, which shouldn't take much time. Just drop me a line in the comments below or via my contact form.

The folks who help me out with this will also get priority to test my forthcoming ColdFusion-based IMAP client, which is currently in development.

Note that while I've gotten several responses already, you should feel free to offer me a translation even if you think that someone else has likely volunteered one for your language already. I'm perfectly happy to get multiple translations for the same language so that I can account for regional differences. So don't be afraid! Thanks.

Boston's own Brian Rinaldi has just authored an article on SitePoint, ColdFusion 8: Believe The Hype. In it, he tells web developers about why they should consider using ColdFusion 8, with details on increased speed, stability, AJAX integration, server monitoring, debugging, and other items. All in all, the article is a great read. Kudos to Brian for working to publicize the great strides that Adobe has made in an already-fantastic development platform.

One topic that I'd like to see more of in ColdFusion articles, though, is why a developer should switch to ColdFusion from another environment, or what the specific advantages of CF are over other languages. Until this kind of thing is addressed, I don't think that people who have already invested their time in PHP or Ruby on Rails will bother to even consider CF, not to mention bother to read CF articles. Brian quotes a ColdFusion developer at The Economist who recently upgraded to ColdFusion 8, who says, "...the whole thing is ridiculously stable." That's absolutely true, but when we have a former PHP/RoR developer saying that instead of a CF developer saying it, then we'll have reason to really shout about it!

(Sheepish) Yes, I know, I should probably just volunteer to write an article myself... but I want to encourage others to do it as well.

For you microformats buffs out there who use my microformats CFC, I have an FYI: I've updated the XSLT stylesheets with the latest from hg.microformats.org. The updated files include:

• hAtom2Atom.xsl
• hreview2rdfxml.xsl
• mf-templates.xsl
• xhtml2vcal.xsl
• xhtml2vcard.xsl

Colin suggested some smart changes for my Clickheat for ColdFusion project, which I've duly commited. Here goes:

• In settings.cfm, I've taken my own email address out. [Doh!]
• In click.cfm, I've replaced hard-coded email addresses in the CFCATCH with the email variables from settings.cfm.
• In click.cfm, I've replaced GetDirectoryFromPath() with VARIABLES.logPath from settings.cfm.
• In index.cfm, I've changed the form action to index.cfm instead of view.cfm.
• In clickheat.js, I've changed URL paths which refer to the root so that they're relative to the root, so that the application will work correctly in any location off the root.

Hareni Venkatramanan of Adobe commented on my previous posting about an issue with how ColdFusion 7 and 8 display labels for small values in pie charts, saying that there was a solution posted for this issue in the 7.0.1 Updater. Indeed there is-- but the solution isn't applied automatically via the updater. Instead, you have to edit the XML files that define your chart styles. Read on to see what the new chart looks like and to find out how to edit the XML file.

Built-in charting capability is definitely one of the great conveniences of using ColdFusion over other languages (although I'd argue that Google's Chart API, which lets any developer call custom charts through a REST API, is eroding that advantage; more on that later). But sometimes there are a few flaws in cfchart that make you look at other charting solutions.

When you click on the "Member login" link on the Text Link Ads site or respond to a comment through the admin section of a Movable Type installation, you'll be presented with a new form in a slightly different manner than you're probably used to: instead of being sent to a new page, or seeing a popup window, the current page darkens, or "greys out", and a form appears immediately overlying it. It's a really neat way to keep the user in the current page context, and it neatly gets around the growing tendency for users to suppress popup windows.

They both do it with Lightbox Gone Wild, which is an adaptation of Lokesh Dhakar's Lightbox project. It's a very easy technique to pull off... link to three script files and one stylesheet in your main page; create a second page containing the code for your form; and then put a link to the second page in the main page with a class of "lbOn". Complete instructions can be found on the Lightbox Gone Wild page.

I know that cfwindow offers some of the same functionality, but it seems to me that cfwindow can't achieve the same level of flexibility as Lightbox.js can. For instance, I think cfwindow is somewhat more limited in how much of it you can style, and is also limited in whether forms in the dialog area can target the whole page.

Boy, am I in a much better mood today than in the last two days.

I had come into the office over the weekend to re-install ColdFusion MX 7 on our production server, thinking that switching to single-server mode from multiple-server mode might solve some of the strange, unpredictable errors that we were seeing on our live site. The re-install, which we had practiced on our dev server first, went without a hitch and the site seemed to perform quite well. But as Saturday progressed to Sunday, the site saw even more errors than before. The same happened as the week began on Monday, with our site becoming increasingly slow and unstable.

The errors that we saw varied, and happened in all different parts of the site, but had one major theme in common: they all had to do with queries. For instance, we saw errors saying that "qQuiz" wasn't defined when we tried to loop over a query of that name-- but the cfquery tag for qQuiz, which executed before the loop, didn't throw an error. We also saw errors stating that queries were timing out, and even the infamous "null null" errors, which you see if you're using cferror templates to provide nicely-formatted errors for your users. Our pages, especially the queries themselves, were taking an amazingly long time to execute-- anywhere from 2 to 15 seconds per query. Try as a might, I couldn't get a handle on what the problem was...

I'm finally ready to share ClickHeat for ColdFusion with the rest of the community. It's a port of Labsmedia's original ClickHeat project, which is written in PHP. ClickHeat shows you where users are clicking on your pages: which links, which graphics, which nav items.

ClickHeat has two main parts: a JavaScript which tracks click coordinates and sends them via AJAX to a .cfm page which saves the information to a log file; and an application which reads the log file and converts it to a click map or heat map. A heat map creates a fuzzy, color-coded map telling you where the greatest amount of click activity occurs on your page (cooler blues indicate less activity, while brighter yellows and reds indicate more activity).

You can check out ClickHeat in my projects section. Please let me know what you think or if you run into any problems using the code.

While thinking about which features to include in one of my applications, I decided it would be valuable to customers (and a good mental exercise for me) to provide the cabability for the app to support different languages, and to support the ability for the user to add new languages of their own.

I will admit that while I did look around a bit for articles on how to achieve this, I didn't look very hard, because the solution seemed readily apparent...

Jake Munson's recent blog entry about ColdFusion's market share made me do some thinking. We all benefit when CF gains market share, since there will be 1) more work for CF developers, and 2) a more robust community, with more open source projects and more code to be shared among us. So how can CF be put in front of developers who aren't otherwise exposed to it? Is there any way its use could be effectively free, like PHP is?

So it occurred to me that there would be a way to get it in front of a large number of developers. There are a few hosting companies who really reach a large audience, such as Yahoo! Domains. Whatever such companies offer as hosting tools is what the population at large will try. Now I ask you-- if someone were to sign up with Yahoo! for their web site, and be given the choice of using PHP or ColdFusion to code their site, which would they choose? ColdFusion, of course!

So why on earth hasn't Adobe struck some kind of deal to get CF offered on Yahoo! Domains? Instead of making someone choose CF as their hosting plan, why not get it to be offered for free to whoever signs up? Adobe would still make money from a licensing fee, and ColdFusion would get huge exposure.

During a recent project, a client wanted to get a spellchecker working with FCKEditor. They had selected Foundeo Spell Checker to work with, which is a nicely-portable implementation since it uses a .jar library as the spelling dictionary-- no need to install a specific library that could only run on Windows or OSX or Linux.

The following instructions are good for the downloaded version of FCKEditor, not for the version that's built in to Coldfusion 8. Because the JavaScript object reference for the editor is different for CF8, I'll have to give instructions for that editor in another post.

When I first started my blog, I was using an old version of Coldfusion that couldn't support any of the modern blog projects. So, I installed MovableType instead, which publishes my blog as static HTML pages. Static code makes it kinda hard to put in all of those nice, dynamic touches that web developers are used to including in their pages, especially of the subject of the blog is often ColdFusion.

But I got it in my head that I wanted to put interesting and ever-changing quotes at the bottom of my blog entries, as I've seen on a few other major sites (you may have noticed the pithy quote at the bottom of this page). More experienced developers will be able to guess right away how I got it to work, but if you're curious about how I did it exactly, please read on.

I'm nearly finished with a new version of Webmail, my web-based POP email client which is written in Coldfusion. But to make sure that it works well in many different environments and with many different POP servers, I'm looking for people to serve as beta testers. Those who are selected as testers and who provide feedback will get a free copy of the code.

As a quick introduction, Webmail provides web-based access to any POP account. It's not intended to be your main email client-- instead, it's intended to be used to read and respond to your emails when you're away from your main client (such as when you're away at a conference, at a client's office, or in a friend's house). Webmail will not delete any of your emails from your POP account unless you specify that certain emails should be deleted.

Webmail now offers the ability to save user preferences including a timezone setting so that all dates are displayed properly, spam keyword recognition, an address book, and even a search function. This new version of Webmail requires ColdFusion 8.

I'm also looking for people who can provide language translations for Webmail (it's about 240 words or phrases, which might take you an hour or two). So if you can test and/or provide a translation, please post a comment below and put your email address in the comment form (I'll be the only one who has access to your email address).

Note: as per Nick's comment, please let me know your web server and email server specifications in your comment. If you have something unique, I'm more likely to include you as a tester.

My previous post addressed how to use a client-side script to validate a To:, Cc:, or Bcc: field that may have more than one email address. Since not all people have JavaScript enabled, it's always a good idea to validate on the server as well-- and with multiple emails, you can't just use the function IsValid('email', [field value]) to validate. So, I converted my JavaScript function to ColdFusion code.

It still happens these days that every so often you have to write different code for different browsers-- you might output different form controls for Firefox versus IE, or might write in different stylesheets for older browsers, or you might write out different JavaScripts for IE5 on the Mac. So what's the easiest way to tell which browser and OS is calling your page?

Obviously, you can look through the server's CGI variables too see this information. But you don't want to parse through it every time you have an if-else condition, so I suggest identifying this information once per request or even just once per session with the following code:

<!--- Get the user's platform and browser --->
<cfif CGI.HTTP_USER_AGENT contains "MSIE">
	<cfset REQUEST.userAgent = "IE">
<cfelseif CGI.HTTP_USER_AGENT contains "Opera">
	<cfset REQUEST.userAgent = "OP">
<cfelseif CGI.HTTP_USER_AGENT contains "Safari">
	<cfset REQUEST.userAgent = "SF">
<cfelseif CGI.HTTP_USER_AGENT contains "Netscape">
	<cfset REQUEST.userAgent = "NS">
<cfelseif CGI.HTTP_USER_AGENT contains "Gecko">
	<cfset REQUEST.userAgent = "MZ">
<cfelse>
	<cfset REQUEST.userAgent = "NS">
</cfif>

<cfif CGI.HTTP_USER_AGENT contains "Mac">
	<cfset REQUEST.platform = "Mac">
<cfelseif CGI.HTTP_USER_AGENT contains "Linux">
	<cfset REQUEST.platform = "Linux">
<cfelse>
	<cfset REQUEST.platform = "PC">
</cfif>

Afterwards, you can just refer to REQUEST.userAgent and REQUEST.platform to get the user's environment.

I've posted an update to my microformats CFC today. There are two bugfixes and several XSLT updates (thanks to Gideon Marken for bringing my attention to most of these issues.):

Bug fixes:

1. microformat classes would not be found in a string if they were combined with other class declarations (i.e., the CFC would find <div class="hcard"> but not <div class="pagetitle hcard">). The regular expression to match classes was updated to fix this issue.
2. the CFC would fail to recognize microformat strings as valid XML if they contained an unescaped ampersand ('&', often found in URLs, should be '&'). The CFC now automatically escapes all ampersands when parsing microformats out of a string.

1. xhtml2vcard.xsl was updated to the latest version as found on http://hg.microformats.org/x2v.
2. xhtml2vcal.xsl was updated to the latest version as found on http://hg.microformats.org/x2v.
3. mf-templates.xsl was updated to the latest version as found on http://hg.microformats.org/x2v.
4. hAtom2Atom.xsl was updated to the latest version as found on http://hg.microformats.org/x2v.

You can download the CFC from my microformats CFC project page.

The other day I found myself scheduling a task which would send out financial reports to users on a daily basis. The task really didn't need to run on the weekends, but there's no way to indicate that in the CF Administrator-- the scheduling form it gives you either lets you run at a specific date and time; daily/weekly/monthly at a specific time; or daily at a specified interval. There's nothing that will let you run a task only on certain days of the week.

Luckily, that's easy enough to control within your scheduled task itself. All you have to do is check to see what day of the week it is and abort page processing if this day is one on which you don't want to run the task. If you check the calling user agent, you can even give yourself the flexibility to call the task to test it on the days you don't want it to normally run. Sample code is below:

<!--- If this page is being called as a scheduled task and the current day is Saturday or Sunday --->
<cfif CGI.HTTP_USER_AGENT eq 'CFSCHEDULE' and ListFind('1,7', DayOfWeek(Now()))>
	<!--- Abort the page with a message --->
	This page doesn't run on weekends.<cfabort>
</cfif>