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.

I recently migrated one of my clients to ColdFusion 9 and not long after the client started getting isolated reports from his people having javascript errors in a data management application that uses AJAX-driven forms talking to CFCs. At first these were very isolated and we weren’t able to reproduce the error, but, as time went on, the reports became more widespread. As I was troubleshooting this over the weekend, I discovered that we were getting javascript errors when trying to interact with this RemoteFacade CFC about 40% of the time.

Using Firebug, I was able to watch the results come back from ColdFusion and noticed a very odd trend. Approximately 60% of the time, the JSON returned from the remote CFC call was as expected. In the other 40%, one of the main data structure names was an arbitrary, machine-generated name instead of the name we had specified in the code.

Here is an example of what we were expecting in the JSON returned from the RemoteFacade.cfc method:

{"DATA":{"CANEDIT":true,"RECORDDATA":{"Field1":"value1"} } }

This is an example of what we would get back from the same request when we would see the javascript errors

{"___IMPLICITARRYSTRUCTVAR5":{"CANEDIT":true,"RECORDDATA":{"Field1":"value1"} } }

See the difference? Our “DATA” key was named completely differently which caused javascript to throw some error saying that variableName.DATA did not exist.

After looking over the ColdFusion code for quite a while and doing some step debugging with FusionDebug I had an idea. I changed all the function-specific structures I had been using from:

<cfset var local = structNew() />
   ....
<cfreturn local />

to:

<cfset var ret = structNew() />
   ....
<cfreturn ret />

Once I changed those throughout the code base and reinitialized my application, all the javascript errors that we’d been experiencing across multiple request types went completely away.

I have an unconfirmed theory that in using the name “local” for my structure, ColdFusion was sometimes getting “confused” on what to return–ColdFusion’s built-in local scope or the method-specific variable I had named local. I don’t really have any way to prove that beyond a shadow of a doubt, but when I made the change, all my errors went away, so I decided chalk it up as a lesson learned for future development and move on to the next problem. Needless to say the client was happy that the issue was fixed and I can say I learned something that day.

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:

1
2
3
4

jQuery.noConflict();
jQuery(document).ready(function(){
   //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.

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.

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!

I downloaded Mark Mandel’s excellent JavaLoader project and dropped it into my webroot. Then I grabbed the 2 JAR files from iText that I needed and put them in a folder named “lib” in the web root (remember this is a POC so I didn’t mind having that stuff in the web root).

Making the classes contained in the JARs available to ColdFusion was a snap thanks to JavaLoader. You create an array of paths to your JAR files (in my case–it also works with directories of class files) and pass that into the constructor for JavaLoader like so:

1
2
3
4
5
6
7
8

<!--- Build an array of JAR files that JavaLoader should reference --->
<cfset loadPaths = arrayNew(1) />
<cfset arrayAppend( loadPaths, expandPath("/lib/iText-2.1.7.jar") )/>
<cfset arrayAppend( loadPaths, expandPath("/lib/iText-toolbox-2.1.7.jar") )/>
 
<!--- Create the JavaLoader object to dynamically load Java classes --->
<cfset loader = createObject("component", "javaloader.JavaLoader")
                .init(loadPaths) />

Once the classes were available, it was very simple to get an instance of the ExtractAttachments class created.

1
2
3

<!--- Create the extractor object --->
<cfset extractor = 
       loader.create("com.lowagie.toolbox.plugins.ExtractAttachments") />

Ok, so now we have the ExtractAttachments class loaded into a ColdFusion variable so we can use it. But now what? Outside of the JavaDoc, there is precious little documentation on how to use this particular feature of iText so it took quite a bit of experimentation and tracing through the Java source code to figure out how to get my particular test PDF file to be used by the extractor object.

The ExtractAttachments class constructor does not allow you to pass in any arguments, so I couldn’t give it my file that way. In looking through the Java code, I found that the constructor was creating an empty FileArgument object and putting it into its internal arguments variable (which is an array that can hold various types of arguments). Turns out there is a setValue() method in the FileArgument that takes a Java file object. Upon finding that, I created a Java file object that pointed to my test PDF and passed it into the setValue() method of the FileArgument like so:

1
2
3
4
5
6
7

<!--- Create a java file object for our source PDF file --->
<cfset inputFile = loader.create("java.io.File")
                   .init( expandPath('/test.pdf') ) />
 
<!--- Set our java file object into the FileArgument argument 
created by ExtractAttachments constructor --->
<cfset extractor.getArguments()[1].setValue( inputFile ) />

The ExtractAttachments constructor only ever puts one argument into its internal array, so I was able to reliably hard code the array index (the [1] in the code sample). Once that file object was passed into the FileArgument, all that remained was telling the extractor object to go to work:

1
2

<!--- Extract the attachment(s) --->
<cfset extractor.execute() />

The result was a newly created PNG file (which is what I had attached to the PDF) created in the same directory where the file CFML page was executing. I’m sure there are ways to specify where that file gets created and do some more intricate things with iText, but for a proof-of-concept test, this one was highly successful.

The slides have been uploaded to SlideSix.com 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.

Dan Wilson will be giving an all-day training session on ModelGlue. Dan is the managing director of the ModelGlue project so you’ll be getting training from one of the main folks responsible for the framework. I have the honor of filling the role of teaching assistant for the class and I am really excited about the event.

Cost for BFusion/BFlex is $10 per person per day so it’s nearly as close to free training as you’re going to find. Registration is not open as of this writing, so be sure to watch the BFusion/BFlex site for more details as they become available.

ColdFusion is the technology that puts a roof over my head and is like that best friend that always makes you feel super comfortable. But, in the last few months, I’ve had this nagging urge to dabble in something different. Call it a mid-programmer-life crisis if you want, but sometimes as I sit at my computer working, the thought crosses my mind that I want to do something new again. “Build something in Flex” my fellow Adobe-centric developer friends might say. I’ve worked a little with Flex in the past and really enjoyed it for the most part (and would really love to get to do some more work on larger projects with it) so that doesn’t really count as something new. I thought about learning Ruby on Rails as that seems to be generating a lot of buzz lately. In the end, however, I felt like something REALLY different from what I do on a daily basis was called for.

I decided on trying my hand at iPhone development for two main reasons. One, I had an idea for an application that would actually be useful to someone besides just me. No, it won’t make me the next iPhone App Store millionaire, but it could potentially generate a few bucks a month that I wouldn’t otherwise have. Secondly, I’ve loved my iPhone immensely since I got my first one over 2 years ago so I thought I’d try to build something that might put teensy-tiny stamp on someone else’s iPhone.

I went to the first ever 360Flex conference that Tom and John put on in San Jose, CA back in March of 2007 and, even as a first event, the content and atmosphere was incredible. They’ve learned a bunch since then with several successive events under their belts so I’m expecting this conference to be great as well. I’m especially looking forward to the entire day of “101″ hands-on stuff on Sunday before the main part of the conference kicks off on Monday. I’ve been reading up some on using the Apple development software and watching some of the iPhone development video content that’s available trying to at least start crawling before the “starting gun” goes off at the event and, I must say, it definitely fits the bill of “different”.

So, if you’re interested in iPhone development and haven’t registered, head on over to the site and get your ticket now before the price goes up again.

Finally, in July, the project was completed and I ordered a few hundred dollars worth of new gear to update a desktop machine that I had sitting idle and installed Ubuntu 9.04 64-bit. There are a lot of great things about Ubuntu linux and I was very impressed with the performance of the OS on a quad-core processor with a pile of RAM.

Unfortunately, it wasn’t a Mac. Let me explain what I mean by that.I was able to get a bunch of things working correctly on Ubuntu including multiple monitors, my development environment, and email/calendar/address book integration. It seemed with every thing that I tried to do, there was some little “gotcha”.

I installed the 64-bit version of Ubuntu 9.04 on my new hardware. Almost immediately I needed to get Flash player running inside Firefox. That turned into a 30 minute exercise of unzipping the 64-bit beta from Adobe and following a couple different blog posts to get it installed–only to have to redo the entire exercise when I updated to Firefox 3.5.

Then there was the issue of mail and calendar support. All my various email accounts are serviced by Google Apps and I use IMAP connections so that my desktop client and my iPhone stay in sync. Neither Evolution or Thunderbird let me set which folders were to be used for Trash, which meant that I now had an extra [Trash] folder in the list of IMAP folders. Had I been one of those folks that just use the web client, it wouldn’t have been an issue. Oddly enough (odd since I’m a web developer) I don’t like using web clients for mail all the time.

I mentioned that I got my multiple monitors working on Ubuntu. I’d purchased a GeForce card with twin DVI connectors so I could run both my monitors natively (as opposed to using the USB to DVI adapter like I do with my Macbook Pro). Multi-monitor support worked, but it treated the two monitors quite differently than any other OS I’ve used multiple monitors on. Application splash screens that displayed at startup were centered across both monitors as if they were one big desktop instead of 2 distinct monitors sitting side by side. That in and of itself wasn’t a deal breaker, but just another example of things you get used to working differently as I’ve used OS X for the last nearly 3 years.

Finally, not having as much choice in good, polished applications even though there are thousands of titles in the package manager contributed to me coming back to the Apple “fold”. GTD apps that fit my working style and a full-featured alternative to iTunes are two examples.

There were several software packages that were analogous to things I’d gotten used to on the Mac. GnomeDo is a respectable Linux alternative to QuickSilver which I use constantly. Workspaces in Linux operate much the same as Spaces in OS X, although there are some key differences when “ALT-Tabbing” between applications.

I’ll be the first to admit that Linux as a desktop operating system has come an incredibly long way in the last couple of years, but after having gotten used to the “fit and finish” of Mac OS X, it just doesn’t quite come close enough for me to leave the Mac.

In order to keep the event free we have removed some hard costs and some benefits you normally get from paid-registration events.

Please be aware of the following:

1. You are responsible for paying for lunch for both days. We have enlisted the services of a local caterer and will be providing lunch each day for $10/day. This includes a sandwich, chips and drink. Please bring cash the day of the event! We will not be able to process credit cards!
2. Limited Edition, Collectible CFinNC conference t-shirts will be available for purchase for $15 with any proceeds going to offset costs and possibly sponsor a planning committee dinner (if we sell them all).

Lunch and shirt purchase is completely optional. You may indicate if you would like to purchase lunch and/or a t-shirt on the registration form.

For more information, please check the CFinNC website at: http://www.cfinnc.com.