Be careful with the ‘local’ scope when migrating from CF8 to CF9

One of the really nice “fixes” included in ColdFusion 9 from a developer’s perspective is the inclusion of an implicit “local” variable scope into which variables created within the body of a <cffunction> tag are placed by default. Previously, developers had to manually add a “var” keyword to variables that should only exist within the confines of the function.

One of the ways of simplifying this that gained some traction among various developers prior to the release of ColdFusion 9 was to “var” a single variable at the top of the function as an empty structure then store any additional variables needed in the function inside it. Many folks, myself included, named this structure “local” so that it would be readily apparent that the values inside were local to that function. This approach worked fine and dandy on ColdFusion 8 and below.

Read More

jQuery head-scratcher and lesson learned

As I mentioned in my last post, I’m working on a pet project in my spare time. It uses jQuery in various places including in the site design template that I purchased to use with the site. The template uses jQuery to expand and collapse menu items in the left sidebar to show sub items for that selection. Because of this, jQuery and a javascript file named custom.js was included in the template. After breaking the template apart to work inside my ModelGlue application, I started implementing some other features that used jQuery with their own associated javascript files, one of which was cfUniform.

As soon as I put the cfUniform code into the page, I started getting javascript errors in the console pane of Firebug. The error would state something similar to “$(document) not a function” or “$ not a function”. Now, I’ve not had a ton of experience with jQuery, but I have used several pre-built jQuery plugins in sites before and I had seen errors similar to this. Normally this error is caused by one of two issues. Either a) you’ve forgotten to include the script block to load the jQuery library or b) your code is loading the jQuery library twice.

I was able to use Firebug to verify that I was indeed loading it and loading it only once but couldn’t for the life of me figure out why I was getting an error. Obviously cfUniform wasn’t really at fault (the error pointed to a line in one of the cfUniform javascript files) so I knew it had to be something on my side. I did some searching on the phrase and found some discussions around jQuery’s noConflict() feature that allows you to reference jQuery with a notation other than using the familiar “$”.

After reading for a while, I opened the custom.js file that came with the site template and found the code below:

   //contents snipped

Since I’m not using any other javascript libraries in this application that might conflict with using the “$” to access jQuery, I removed the noConflict() line, but that didn’t fix my problem. On a hunch I did a search/replace through the custom.js file replacing “jQuery(” with “$(” so that references to the jQuery library in this file would be accessed with the same syntax as in all the other javascript files. Lo and behold, all my errors in Firebug’s console went away and CFUniform began behaving as expected.

While I don’t understand all the underpinnings of why this worked, I’ll take it as my “lesson for the day” that in the future I need to always make sure that all the various jQuery plugins and code that is used in my applications need to reference the jQuery library with the same syntax.

ColdFusion 9 caching settings to watch out for

Like a lot of developers, I’ve got this pet project I’m working on in whatever spare time I can find between client engagements, home maintenance, family obligations, etc. I’m using it as an opportunity to work with some of the new features of ColdFusion 9 (ORM mainly), ColdFusion Builder Beta and features in development for the next release of ModelGlue 3.

Recently, Bob Silverburg has been working on a significant overhaul of the scaffolding feature used by ModelGlue to automatically create CRUD forms for the various data objects in your application. Particularly exciting to me is that you can now override the built-in code templates with your own. Bob wrote a proof-of-concept application that uses the excellent cfUniform custom tag library to build standardized forms and validations (see my previous post on cfUniform if you’re not familiar with it). Since I’m pretty particular about how my project files are arranged, I proceeded to place the css, javascript and image assets into the folders where I wanted them and use ColdSpring to create a configuration bean to pass to cfUniform when I called it. That’s where the trouble began.

I had to make a couple of changes to the code generated in the custom scaffold CFC in order to have cfUniform see the custom configuration that I had set up. No matter what I did, when the scaffolding engine generated the code for the view and the XML fragment for the event-handler, the changes I made inside the CFC weren’t included. I spent a couple hours scratching my head, tracing the request cycle, restarting my local ColdFusion instance and always got the exact same code that was in Bob’s original example CFC. Finally, I decided to change the name of the CFC and update the associated bean configuration in ColdSpring. On the next refresh, I saw my changes reflected in the code generated by the scaffold!

With that in mind, I checked the settings on the Caching page of that instance’s CF Administrator. Sure enough, the Cache Template In Request, Component cache, and Save class files options were checked. I cleared those check boxes, pressed the Clear Template Cache Now and Clear Component Cache Now buttons below and have had no trouble since. Obviously there are situations where you want these enabled, but rarely ever should they be needed on a local system being used for development.

So, the moral of my painful story–if you’re making changes to code that’s not being reflected when you test browse your application, don’t forget to check the settings on the Caching page in CF Admin. It just might save you a couple hours and a few gray hairs.

Going beyond CFPDF with iText

This week I was working on a proof-of-concept for a customer in which we wanted to extract attachments from a fillable PDF form after its submission. After trying the usual CFPDF tags, reading the documentation, and getting nowhere, we decided to try to attempt to use the iText PDF library for Java from within ColdFusion to extract the attachments.

After doing some reading through the JavaDocs for iText, I found that it includes a class called ExtractAttachments that “…lets you extract the attachemnts of a PDF.” Since this is precisely what we wanted to do, I thought for sure this would be a simple affair and I’d be able to finish what I needed to do and turn in early for the evening. Not quite!

Read More

Slides from my ColdSpring session at CFinNC

I’ve attached my slides from the my CFinNC session called “ColdSpring: Solution to a Problem You May Not Know You Have”. I’ve also included the example files that I referenced during the presentation.

The slides have been uploaded to or you can view them below. A PDF version of the slides is also available for download.

Thanks to all those folks that attended my session. Also a huge thanks and a job well done to the conference committee and volunteers that made the conference happen.