Phillip's ColdFusion Blog

I've decided to step outside my comfort zone and try out a new framework, CFWheels. CFWheels describes itself as "an open source CFML framework inspired by Ruby on Rails." It advocates conventions over configuration, which seems to be the latest craze to hit CF frameworks (see ColdBox and FW/1 for two others).

Since I'm going outside my comfort zone, I think CFWheels is a good framework to explore since it supports several unfamiliar and/or uncomfortable areas for me:

• Convention over configuration - I am a long time Fusebox user
• ORM - I proudly admit to being a control freak when it comes to the data layer
• URL rewriting - More than just pretty URLs?

Creating a New CFWheels Site

According to the documentation, setting up a new CFWheels application is rather straightforward. Download CFWheels, extract the zip file to the web root, and voila, a new CFWheels site.

For my first site, it was indeed this easy. I created a directory, extracted the CFWheels files into it, and I was done (almost...).

The Default Route

I wanted the site to be under a directory named "reading" After creating such a directory and adding in the CFWheels skeleton, however, I immediately hit an error message. Not a ColdFusion-generated error, but a rather friendly CFWheels error message indicating that a view could not be found:

After poking around the documentation and code a bit, I realized that the default route for a fresh skeleton application was set to look for a file named wheels.cfm under views/wheels. The config/routes.cfm template has the following lines of code to set up the default action:

Translated, the addRoute() line tells CFWheels to look for a controller CFC named wheels in the controllers directory and a CFM template named wheels.cfm under a subdirectory named wheels in the views directory. (This conventions thing is rather handy.)

The error message I received pointed to a problem I introduced while setting up the site. I renamed the default "wheels" views directory to "reading," not realizing that I was breaking the default route.

The fix was simple, either restore the views/reading directory to views/wheels, or, and this is the option I chose, change the route to to point to the existing views/reading directory:

Next Steps

So now that I have a happy CFWheels skeleton site, what next? The site I had in mind is a simple application to track what books I have read, so I need to take a step back and design the model and the screens, pardon me, views, that need to exist.

Once the basic design is set, I want to explore CRUD automation using CFWheel's ORM. I need to see if I can just let go and allow a framework to automate a good portion of the data layer.

I use a Mac for my personal work and a Windows XP machine for gaming and a few PC-only apps. I never thought twice about upgrading Windows to Vista, but I am certainly thinking about going to Windows 7.

So what brought about the change of heart? I set up a new computer for my mom last night, a HP slimline...wow, is it shiny and kind of cute, which came with Windows 7 Home Premium on it. My first experience actually driving Windows 7, and I came away really liking the changes and polish added to the OS.

The graphics are nice and shiny, looks like they took a page from Apple's design book, the speed is there, and the features and improvements really look like someone cared about this release of Windows. The improvements in searching alone are a big plus in the pro column on the go-and-get-a-copy list.

Many of the features I like about OS X, the speed, the graphics, Finder and Spotlight, are pretty much all there on Windows 7. Just one question: will it run Civilization IV? ;-)

Just maybe a trip to Micro Center is in order this weekend...

It was bound to happen.

I no longer get to code as often as I would like, so when I got the opportunity to make a quick fix to help bring my company's software up to CF 9 snuff, a problem with nested WDDX packets, I decided to keep the task to myself. A short time later I had the solution, wrote the necessary code, checked it in the browser, and then committed the file to source control feeling the old coding euphoria set in.

This morning, however, one of our developers called over the cubicle wall saying something was not right. Yep, I made a syntax error. My sense of accomplishment withered into feeling like a newbie. I made a mistake, one that I often coach others on: I did not sufficiently unit test my code change.

Once I got over the blast to my coding ego, I made the (small) code fix, unit tested again, and committed the file to the repository.

My lesson learned is two-fold:

First, never overestimate your own coding ability. There is always room for improving and refreshing both your language knowledge and your development practices.

Second, find time out from designing software to actually write some code. Do not let your code-fu wither due to disuse.

From time to time I have to switch out of ColdFusion into Java to get a task accomplished. The latest was writing a password callback class for a web service integration project using ColdFusion, aka the Axis web service engine, and WSS4J.

[More]

One of my recent projects was to design a web service-based API for an existing Fusebox 3 application (more on that later). The data exchange has to be digitally signed, which requires working with public and private keys within ColdFusion.

ColdFusion uses the Java keystore within the JRE to handle keys and matters of trust. A keystore is simply a storage location for keys and certificates. Most keystores are physical files protected with a password. By the way, the default password for the ColdFusion keystore is "changeit."

During the prototyping and development phases, I determined that using a self-signed key was faster and easier than having to go through the process of obtaining a "real" signed key.

Note: Self-signed keys are useful for development, but a real key should be used in production environments.

General Syntax

The general syntax for generating a self-signed key pair using the Java keytool utility is:

My project required using the RSA key algorithm. If you do not specify the algorithm to use, the keytool utility uses DSA.

Using the Keytool Utility

Using the keytool utility requires going to the command line, so GUI-lovers beware! I'm going to use the Windows command line in my examples below.

The keytool utility lives in the bin directory of the Java runtime associated with ColdFusion. The default keystore for ColdFusion, named cacerts is in the lib/security directory, so any references to it must be the full path.

To list the current contents of the ColdFusion keystore, use the -list switch:

Generating a key pair uses the -genkey switch. In this example, I create a RSA key named mykey stored in the cacerts keystore, and then self-sign it:

To share the public key with another application, you will need to export the certificate from the keystore using the -export switch:

Importing a key also uses the keytool utility, this time with the -import switch:

Note: Once a key exists in the ColdFusion keystore be sure to restart the ColdFusion Application Server.

I came across a very strange and unexpected problem with a SQL Server 2005 UDF yesterday that continues to puzzle me. First, the cast of players:

• ColdFusion MX 7
• SQL Server 2005
• A table-valued function
• Puzzled developers

In case you are not familiar with table-valued functions, they are functions in SQL that return a table, as opposed to the more traditional scalar value.

We had to change the data type for one of the columns in the returned table from decimal to text to fix a bug. Nothing a simple ALTER FUNCTION statement could not handle.

Script, run, test, same error, what?

Maybe something is cached on the SQL Server side. Let's try dropping and recreating the function.

Script, run, test, same error, ???

Something very odd was happening. Only after restarting the ColdFusion Application Server service did the error go away.

I am still searching for an answer. Surely ColdFusion does not cache database object information...?

CFUnited is this week, and I will be there from Wednesday to Friday. Since this will be my fourth CFUnited - I have the t-shirts to prove it - I have a pretty good idea of what the sessions and format will be like. The three days will be packed with information that is nearly impossible to remember without rereading any notes I happen to take.

CFUnited sessions are far to short to fully cover most topics. ColdFusion is just too deep and rich to do so. Instead, I approach each session with the following goals:

• Learn one new aspect of the topic. For example, what does an XSS attack look like in the logs.
• Get introduced to the broad aspects of the topic. For example, what are the high-level abilities of ColdFusion to connect to a Microsoft Exchange server.
• Get acquainted with the latest buzzwords and "must-haves" in the ColdFusion world. A little tongue-in-cheek, but unfortunately I do not always have time to keep up with the various email lists and blogs.

Each session is an opportunity to become interested in a new or different approach to solving a problem (and everything is a problem to resolve). Just leave room for chatting with vendors and maybe even other developers. ;-)

I have used a variety of version control methods and products over the years. In the beginning, I (infrequently) added a digit or date to the end of the file name, an effort that was largely ineffective and highly subject to user error. :-) Then, corresponding with a job change, I was introduced to version control software in the shape of CS-RCS from ComponentSoftware, based on GNU RCS. After a couple of years, the development team made the shift to Subversion, my personal favorite. To be complete, I will throw in a year of pain using Visual SourceSafe.

[More]

I (finally) took my first dive into test driven development (TDD) with a personal project I recently started. I admit, the first thought that came to mind when I first read about the red/green/refactor process included a man, flannel, and duct tape. ;-)

I decided to use MXUnit for my unit test framework. Using the Eclipse plugin made running the tests very easy.

Instead, the hardest part for me was fighting the impulse to just write code. Red/green/refactor is all about first writing the test, watching it fail, then writing the code. Test, fail, code, and repeat until the test passes. Several times I caught myself writing code outside of the confines of the current test case. It was far too tempting to listen to the little voice that says, "It will be easy to add this feature too. The template is open anyway."

Writing the tests first was also a challenge. I had to sit back and really think about what behaviors and data my user bean would contain. I actually had to formulate a plan before coding! Time to practice what I preach about on almost a daily basis at my paying job.

I have yet to get to a true refactor stage, but I imagine it will be soon. It is too early in the unit testing and coding phase to have enough code to refactor.