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?

A while ago a colleague and I were working on a timesheet application in Flex. The idea was that you could commit a custom timebar object, generated in flex, and it would update the dataset in the back end using the ColdFusion flex gateway.

I came across the code recently, and decided to tidy it up a bit, and make the query dynamic, based on the Struct contents. The obvious limitation to this is that your Struct and your database schema have to match exactly.

I won't go into the Flex application here, but I've emulated its input arguments here with a pre-populated structure.

Notice that this code also calls the CFC object at the end. The data itself isn't massively important, it's a time object for recording tasks.

Next we have the function, which accepts a Struct() argument called 'taskStruct'. I then loop through the structure, and populate a SQL query using the keys from a collection. The only logic is a check to see if it is the last structure element, as this controls the ',' placement.

That will insert your Struct into a database, in small and tidy manner. It was somewhere around here that we started using cfproperty tags, and creating strongly typed objects for Flex.