Shaun Mccran

My digital playground

01
O
C
T
2009

Introducing third party applications into your frameworks, good practice?

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:

view plain print about
1<!--- setup vars --->
2<cfset variables.destination = "C:\dev\images\testimage.jpg">
3<cfset variables.source = "C:\dev\images\testimage.jpg">
4<cfset variables.width = "100">
5<cfset variables.height = "100">
6<cfset variables.exec = "C:\dev\apps\imageMagick\convert.exe">
7
8<!--- executing an external application version --->
9<cfexecute name="#variables.exec#" arguments="-size #variables.width# #variables.source# -geometry #variables.height# -strip #variables.destination#" variable="imageinfo" timeout="3" />
10
11<!--- CFimage version --->
12<cfimage source="#variables.source#" action="resize" width="#variables.width#" height="#variables.height#" destination="#variables.destination#">

01
S
E
P
2009

Incorrect error message reporting using CFFile action rename

During a batch process that I was writing recently I was using a CFfile operation to rename some files.

When running it I came across this error message:

view plain print about
1Attribute validation error for tag CFFILE.
2The value of the attribute source, which is currently "C:\fullUrl.jpg", is invalid.

This is the calling cfml code. The actual variable values aren't important.

view plain print about
1<cffile action="rename" source="#variables.tmpFileLocation#" destination="#variables.dir#/#variables.photoid#.jpg">

So I checked and doubled check the source url, and manually browsed to the directory and viewed it. The file was right there! I had a wander around online and found that this isn't a new issue, but more a bad error report.

The error isn't actually relating to the 'source' attribute at all, but rather the 'destination' attribute. In this case it was a file/folder permissions problem. (I didn't have write access). It was simply a case of Coldfusion server reporting it incorrectly.

28
J
U
L
2009

Finding the system file storage in AIR

When progamming an AIR application, you may want to make use of the applicationStorageDirectory available via the flash.filesystem package to store temporary files/folders. You can find where your system is storing these files by doing something like the following:

view plain print about
1var f:File = File.applicationStorageDirectory.resolvePath("Test.txt");
2trace(f.nativePath + ' is where my file is stored');

This will give you an absolute path to the local system file storage location. Handy for multi platform applications, as Pc and MAC based systems will use different default storage directories.

03
J
U
L
2009

Function for getting the last modified date of a template

Whilst looking at creating dynamic Sitemaps for Google bot spidering I found that I needed to populate an XML node with the last modified date of the templates. I figured there must be a programmatic way of doing this, so after some searching around this is what I ended out with:

view plain print about
1<cfset mod_time = createObject("java", "java.util.Date").init(createObject("java", "java.io.File").init(getcurrenttemplatepath()).lastModified())>

This creates a java object, using the date and file utilities we can use 'getcurrenttemplatepath()' to provide the path data, finally referencing the lastModified property.

A handy and relatively quick way of getting the last modified date.

It is a bit of a mouthful though, so might be easier to create it as a handy referencable object:

view plain print about
1<cffunction name="modStamp" access="public" returntype="date" output="no" hint="Gets the last mod date of a file, returns a ts">
2    <cfargument name="file" type="string" required="yes" hint="File to get mod date">
3        <cfset var mod_time = now()>
4        
5        <cfif fileexists(arguments.file)>
6            <cfset mod_time = createObject("java", "java.util.Date").init(createObject("java", "java.io.File").init(arguments.file).lastModified())>
7        </cfif>
8        
9    <cfreturn mod_time>
10</cffunction>

Then you can just do:

view plain print about
1<cfset variables.fileMod = modStamp()>

_UNKNOWNTRANSLATION_