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.

NiftyPlayer is a free, open source Flash file that you can embed into your page and play MP3 files without worrying about what audio player is installed on the visitor’s machine. The best part for my situation is that the player is completely controllable through Javascript. That means that I could completely “hide” the UI provided by the Flash file by setting the height and width of the Flash object to zero and use custom javascript methods to craft my page to do exactly what I wanted it to do.

Having a Javascript API to the Flash player object means that you can simply added the following code toplay a track:

<a href="#"
  onClick="niftyPlayer('previewPlayer').loadAndPlay('fileName.mp3')">
      Play
</a>

NiftyPlayer also provides a way to register different types of events and pass a reference to a custom block of Javascript code to be run with that event fires. For example, you can register the “onPlay” event to change the source of an image on the page when a track starts playing and then register the “onStop” and/or “onSongOver” event to change it back when the track is either stopped manually or runs to completion.

Having this ability to completely hide the UI of the Flash object and control it with Javascript code was key for us as it allowed us to use NiftyPlayer in a design that had been created by an outside design firm without having to dive into the .fla file and update the colors, fonts etc originally used by the author. Using the Javascript API, I was able to control the source of an image (play and stop images) as well as update the CSS class of the div containing the currently playing track while it was playing and reset it back to its previous state when the user pressed the stop button or when the track finished playing.

Because of Flash’s near-ubiquitous install base, NiftyPlayer is a great option to easily add MP3 playback capability to your web application and know that it’ll “just work”.