One of the best practices that I've been using more and more is ColdFusion's ability to add CFC object references to scopes. By this I mean that it is possible to create a shorter friendlier scoped variable that you use to reference your CFC's.

In your Application.cfc you can map out all your CFC references, this gives you a much shorter variable name to type each time, and it caches the CFC.

Put any references like this in the 'onApplicationStart' function. You do not need to lock the scope in this function, and if the code within it does not run successfully then it does not continue running the application. It will try again on the next page request.

The caching functionality here is great, not only will Coldfusion create a handy short name for CFC, but it will actually run through the code, and stop on any errors. If you deliberately introduce a code error into one of your objects you will see the Application halt and show you the error. For me this is reason enough to move all my business logic into CFC's. This essentially means that it is not possible for a user to get part of the way through a application and find an object based error.

Using this in conjunction with a framework such as FuseBox allows you to load, parse and cache the CFC object, all before your actual display layer has been invoked.

The example below uses the FuseBox function 'onFuseboxApplicationStart' of starting an Application.

Changing the 'fusebox_parameters.mode' value allows you to set this caching at an environmental level, so no caching for development, or caching for live

One of the more recent additions to my Coldfusion frameworks is masking the more ugly URL's using Isapi rewrite. In this article I'll be using Helicon's Isapi ReWrite, but Apache re write works in much the same way.

Usually in your Coldfusion frameworks, most other technologies as well, you are passing around a variable or two to control the page content, and more often than not it is in the url. It never looks particularly clean if your URL has a long name value query string behind it, like this:

Cosmetic reasons

So for two reasons URL rewriting seems like a good idea.

Firstly to mask those ugly URLS with a url rewriter. On a basic level this will re write specified request to the URL you tell it to, taking your ugly list of name value pairs and changing it into a user friend URL. If you are pitching this to a client this looks a lot more professional.

Security reasons

Secondly there is an added security benefit here. The URL gives a lot away about a website, like what the code base is, and is potentially a window on the internal workings of a website. Take a normal FuseBox application for example. The normal URL might be:

From here it is very easy to start messing around with the controller names, trying to dig out an 'admin' controller, or other common function controller. Similarly adding values to pages where it is obvious a Query has been fired is an easy way of testing of the developer is using 'cfQueryParam', with potentially disastrous results.

Along the same lines it is quite simple to inject form values into the URL (like this http://www.mccran.co.uk/index.cfm/2009/7/30/Cross-site-Script-hacking-using-the-GET-method). By masking the URL and the values you make it considerably more difficult to do this, after all if you can see or get to the URL, how can you fool around with it?

So far I am implementing a rewrite script that will rewrite URLs into friendly strings, here is a modified version of the .htaccess file I'm using.

This code starts off by turning the rewriteEngine on, then setting the rewriteBase, this is typically your webroot, or the root of the site the file is for. Then it rewrites any URL params to the URL string.

The main part of the code is where we set individual rewriteRule's for each URL. The first example (home) looks for any URL requests to the 'home' string, and re writes this to the URL in the regular expression (index.cfm?go=controller.home). Pretty straight forward really.

There is a lot more you can do with this, and hopefully I'll get to explore rewriting in more depth in the future.

I was discussing some ideas for an application framework this morning with the team, and one of the issues we hit upon was having a common directory for templates, but serving them up as if they were from a different directory.

The idea is to have one instance of a reusable skinnable template, that appears to live on several sites.

IE all the content lives in "webroot/content/templateName.cfm", but is actually served up by many sites, IE "127.0.0.1/site1/template1.cfm", "127.0.0.1/site2/template1.cfm" ... etc

In this way they can be re skinned or adapted as needed, and they aren't database driven. The main stumbling block for the discussion was the need to actually create blank versions of each of the named templates, in each of the sites, as ColdFusion server would error on the request.

I spent twenty minutes trying to work it so that my Application.cfc's onRequest or onRequestStart method would intercept the request before it was actually made, but that just wasn't working. My other idea was to use the onMissingTemplate method, but the server is only running ColdFusion 7, so that was a no go (I figured I could catch the missing template request and just re path it, although I'd have to assess if that was really inefficient due to almost every page request logging as failed).

My eventual solution was Isapi rewrite. I am re writing all the requests to the same template, and just passing in the template variable. In that way I can request pages that don't actually exist, but they appear in the url.

Create an index.cfm template like this:

For this example I am using the free version of Helicon's Isapi rewrite, you can get it here: Link to Helicons Isapi re write

In the example below I have altered the first page link to look like it is actually a .cfm template request, just in case you want the url string to have a .fileextension look to it.

So when you fire it up and test it you just see /page1, /page2 etc, and the pages don't actually exist.

I'm not experienced enough with Isapi rewrite to know if there is a downside to this, but bookmarking in a browser still works correctly, so I can't see an issues at present.

If you are anything like me, everyday you are smothered in a stack of emails from various companies all delivering html formatted, image heavy flyers persuading you to buy whatever dead horse they are flogging. I know it is my own fault, after all I signed up to them in the first place, I've only got myself to blame. As I find myself checking (and deleting) these email on an Android mobile device now it has become hassle-some. So I set out to unsubscribe from the majority of them, which is where the inspiration for this article came from.

In a short period of time I have unsubscribed from around a dozen different email newsletters, and because of this the differences in the methods used to accomplish this have become glaringly obvious. I was very surprised at the variations in the methods used, some are very user friendly, and others are very much not. I won't name the companies involved.

Case one:

By far the easiest user interaction, this is a simple link from an email that provides you with a screen confirming your UN subscription. No prompt is required from the user, you are simply unsubscribed. All the data is passed seamlessly behind the scenes.

Case two:

Almost the same as above except that you are taken to a screen where you have to commit an action. You are presented with a screen displaying your email address, and prompted to click a button to confirm the UN subscribe action. This may be a handy safety net to step errors from the casual clicker.

Case three:

Clicking on the link from an email takes you to a generic page with a form on it. They have not transferred any form of token from the email so you are prompted to enter the email address you want to UN subscribe. Entering your email address takes you to a screen confirming your action. This additional step is unnecessary, and doesn't add any value at all.

Case four:

In this scenario we are passed to a page where we have to login. The subscription details are attached to an account application, and as such your credentials need to be verified. Based on passing an encrypted token from the email a user could easily be logged in automatically. Actually requiring a username and password adds an additional level of complexity. Once I logged in I then had to navigate to the subscription settings and choose to unsubscribe with a form similar to the ones mentioned above.

Case five:

In the most convoluted example I have come across so far I actually had to create an account. I arrived at the UN subscribe page and found that to subscribe did not require an account, but to change my subscription options did! This was a very strange scenario, requiring a user to create an account to stop emails. Once you have created an account the subscription options were managed through a form like the ones mention above.

Conclusions

I think the thing to keep in mind with functionality like this is the balance between usability and the business objectives. An obvious point to note is that businesses do not want their users to UN subscribe to their emails. This is their user base and they do not want to lose it. Still it is worth considering just how you interact with your customers, even when providing functionality you do not want them to use.

After all you can always just 'Mark as Spam'.

One of the more overlooked forms of testing (you do test don't you?) is regression testing. I'm a big fan of scripted testing using both scripted tests to actually run against your code base (think cfUnit or Junit) and scripted testing as in a basic word doc of testing instructions.

This word doc can be as simple as 'click button N' - what displayed on screen? You can literally just list the actions, expected consequences and actual conqequences.

Regression testing is the practice of going back after a release and testing the functionality that was already present. IE did you break anything by releasing your new functionality. Often the business and IT focus is on the shiny new development, not the integrity of the existing application.

Developers in particular are guilty of zoning in on the specifc area that they are directly involved with. This can sometimes lead to other areas suffering, especially if you have an OO application layer. In just how many places is each individual object referenced? A change to it may work in one area, but have devastating consequences in another.

I've seen cases of this where its been months later before an error has reared its head, and without an accurate change log it can be difficult to track the root cause down. Needless error tracking and bug fixes take developers away from actually developing, and essentially cost the business money due to bad practice.

I mentioned scripted testing above as it has had unforseen beneficial consequences. If you have done anything like this in the past, your regression testing will be very easy. You will have a handy library of repeatable scripted tests, so it is very easy for you to measure the previous results against any new tests you might perform. Thus making it instantly obvious wether your functionality is still behaving as it was before the release.

A recent development involved some changes to a large script that was using a product called ImageMagick (link). It is an image manipulation tool that allows you to perform transformations and other actions on image files. The product seems stable enough, and can be executed from a web interface using cfexecute, in a kind of command line prompt method.

It got me thinking as to why the application wasn't using cfimage, and then lead me to examine the wider topic of whether to use ColdFusion's in built functionality, or opt for other third party products.

I can think of a few obvious deciding factors for both pro and con, the first that springs to mind is performance.

Is there a marked performance difference between a ColdFusion function, and the third party application? Is it better to pass the load of to the operating system, rather than have ColdFusion perform whatever processing function it is supposed to do? In this case it would be a race between cfexecute, and cfimage, so there may be very little difference in it.

The second major point that springs to mind is the knowledge base of the developer, and the structure of whatever framework you are using. What I really mean by this is 'if your chosen technology can perform a function, why not utilise it to its full potential?' . It seems a bizarre choice indeed to deliberately not harness a function that your platform can already provide, and instead introduce another code base or application into the framework.

It also introduces another hurdle for the development staff, they may well be familiar with how an existing Tag works, but be totally unaware of the third party application, as was my case here.

A long winded intro, but here is the code I used:

A simple Fusebox reset function

I am always forgetting the application URL for resetting fusebox frameworks, so instead of having to type out the entire fuseaction url, and appending the load variables, and the parsing variables you can create a fuse action for it.

The code above will build the URL using the fuse action variable (IE 'action=' or whatever you have specified). It also uses the fusebox password set in your Application.cfc.

There may be a small security risk involved with this, so don't use an obvious name for the function. Also they would need your fusebox password.

Even then thought the only potential issue I can see with this is that someone may empty your framework cache and rebuild your application. Which isn't all that bad?