What I eventually found was, when trying to load an object using an AJAX call to RemoteFacade.cfc, any object that had a property that was an array of other objects was not returned to Javascript. It wasn’t even that it was sent across as an empty property. The property absolutely didn’t exist in the JSON returned by the CFC. I used the ColdFusion debugger to verify that the array existing in the object immediately prior to the <cfreturn> statement and then examined the JSON return using Charles Proxy only to find out that those properties weren’t in the JSON. All the normal string, numeric, date, etc type properties were returned just fine, but any properties composed of other objects were missing.

As near as I can tell, the culprit is the serializeJSON() method that ColdFusion uses to convert complex objects into JSON notation. It doesn’t seem to work correctly on ORM objects. To test my theory, I manually built a structure and inserted each simple property from the ORM object. I then created a key in the structure that was an array and manually populated several items in the array each with a structure of data. When I returned that from the CFC as JSON, the array and all the structures it contained came across the wire just fine.

I’m not sure if this is a bug in the serializeJSON() method or if serializeJSON() wasn’t meant to handle objects. Whatever the case, this issue leads to quite a bit of extra work if you need to return an object via JSON and include its properties that are composed of other objects. I’d definitely be interested in hearing from anyone who has successfully done this with ORM and AJAX to see if I’ve done something incorrectly in my code.

<cfset Team = createObject("component", "model.Team") />

Now, using the New keyword, we can shorten that to

<cfset Team = New model.Team() />

But wait, there’s more!
When you use the New keyword, ColdFusion will automatically look for and run any init() method that exists in the CFC. It also respects any arguments that your init() method specifies, meaning that if you have a Team.init() method that can accept team name, color and manager arguments, you can build them right into your the same line of code used to create your object like so

<cfset Team = New model.Team( "Bumblebees", "Yellow", "Benny Bee" ) />

Likewise, as you’d expect, named arguments are still supported. So if you had to send in arguments out of order or needed to omit some optional arguments at object creation, you could do

<cfset Team = New model.Team(
              manager="Benny Bee",
              color="Yellow",
              name="Bumblebees") />

I personally am going to make a point to start using this in my code because I can never seem to spell the word “component” correctly in the createObject() method.

The class was taught by Sean Hedenskog in San Jose, CA where the headquarters for the company I was working for at the time was located. That company had decided on Allaire Spectra 1.0 as the basis for an enterprise content management system so several of us went through the Fast Track to ColdFusion course in preparation for Spectra training some weeks later.

I know there are are a lot of people out there who have more time with ColdFusion than I do. I started with version 4.5 and, if memory serves, our company was one of the first to deploy ColdFusion and Spectra onto Solaris-based servers. Even so, I feel like I’m somewhat of an old-timer these days. That’s a good thing however, since it means we’re getting more and more new people using ColdFusion.

A lot has changed in the 10 years since I started that class. Coming from a strictly HTML background with a little bit of classic ASP thrown in, even the beginner class posed quite a challenge for me. Simple things we don’t give second thoughts to such as calling a custom tag (there were no UDFs or CFCs then remember) were hard for me to get my head around. I remember having an especially difficult time trying to figure out how arrays and structures worked

Along the way I’ve been privileged to associate with some very talented and helpful folks. Not long after we started the Spectra project, my company brought in some folks from the Allaire consulting group. Matt Stevanus was one of those folks and quickly became a great friend and mentor. We kept in touch periodically after that project was over and a little over 3 years ago I got the opportunity to work with Matt again when I started consulting with Universal Mind.

A couple years ago I met another guy who would help shape my professional career–Dan Wilson. Dan is widely known these days as a driving force behind the ModelGlue project. Dan and I had an opportunity to work on a long-term project together and he and I’ve enjoyed working with him on various things ever since. It was Dan that really got me over the “OO hump”, convinced me that I needed to start blogging more and to submit topics to various conferences to speak on.

Finally, there are dozens of people out in the ColdFusion community doing blog posts, open source projects, MeetUps and more that have contributed to my success. To everyone, I say a hearty “THANKS!” (and my mortgage company loves you too).

So, here’s looking back at a great 10 years while looking forward to many more ahead!

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.