The _CF_NODEBUG Parameter

Most people know that enabling request debugging output via the ColdFusion administrator has some overhead. If you are running a CFC heavy application the performance hit can be quite noticeable. To get around the performance issues you may be tempted to use <cfsetting> with the showdebuoutput attribute set to false. While this does indeed suppress the debugging output, it does not disable the debugging service or alleviate the performance issues you may see with debugging. You can confirm this using the following template:

[More]

Flex Remoting to CFCs under a Fusebox 5.5.1 Application.cfc

I recently started using Fusebox again and one issue I ran into was that Flex Remoting calls to CFCs under my Fusebox application were not working. (The application in question used an extended version of Fusebox's Application.cfc.) To work around the issue I put the remote components under a different, minimal, Application.cfc which used the same name as my main applicaiton. Something like the following:

<cfcomponent>
<cfset this.name="myApp" />
</cfcomponent>

This fixed the issue, but I was still a little puzzled. It is well know that the Application.cfc onRequest method doesn't play well with Flex Remoting, but I looked at Fusebox's Application.cfc and thought it was handling the issue with the following code in onRequestStart:

<!--- ensure CFC / Web Service / Flex Remoting calls are not intercepted --->
<cfif right(arguments.targetPage,4) is ".cfc">
<cfset doCompile = false />
<cfset structDelete(variables,"onRequest") />
<cfset structDelete(this,"onRequest") />
<cfreturn/>
</cfif>

Well, today I had a little bit of time to look into this and it turns out that for Flex Remoting requests the targetPage is "/flex2gateway," not the name of the target CFC. It was a bit of a "duh" moment, because if you have ever looked at a services-config.xml file or watched Flex Remoting requests via a proxy like ServiceCapture then you know the URL used is something like http://localhost/flex2gateway. Anyway, to fix the issue I ended up modifing the Fusebox Application CFC code above to the following:

<cfif right(arguments.targetPage,4) is ".cfc" or findNoCase("/flex2gateway",arguments.targetPage) gt 0>
<cfset doCompile = false />
<cfset structDelete(variables,"onRequest") />
<cfset structDelete(this,"onRequest") />
<cfreturn/>
</cfif>

Now I no longer need to remember to add a custom Application.cfc for remote CFCs.

It is important to note that Flash Remoting can be configured to use any URL, but this at least covers the default configuration for ColdFusion.

Fusebox ColdSpring Lexicon Mod

For those using the "traditional" XML flavor of Fusebox, starting with Fusebox 5.1 the skeleton application includes a lexicon that makes working with ColdSpring a breeze. The only problem with this lexicon is that there is no way to use a ColdSpring bean factory that lives outside of the Fusebox application context. This becomes a problem when you want to use ColdSpring remote proxies for AJAX or Flex, as those requests may not have access to the Fusebox application context. To get around this issue I modified the lexicon's initialize tag to support a parent bean factory. Now you can do something like this:

<cs:initialize
coldspringfactory="servicefactory"
parentbeanfactory="application.mySharedBeanFactory" />

which will cause the following to be written to your parsed files:

<cfset myFusebox.getApplication().getApplicationData().servicefactory = createObject("component", "coldspring.beans.DefaultXmlBeanFactory").init( defaultProperties="#structnew()#" )/>
<cfset myFusebox.getApplication().getApplicationData().servicefactory.setParent( application.mySharedBeanFactory) />

This approach is very similar to what ModelGlue does with it's ModelGlue_PARENT_BEAN_FACTORY setting.

If you are interested I've attached the modified initialize.cfm to this post. I've also posted this mod to the Fusebox 5 group to see if there is any interest in making this change in the release version.

Debugging Flex with ColdFire

Recently I went back to doing Flex work and one of the things I immediately missed was ColdFire. So I decided to take a look to see what could be done to get my favorite debugging tool working with CF powered Flex applications. Turns out it wasn't all that hard. First though, check out the video below to get an idea of what I'm talking about. (Sorry, no sound as I recorded this at work.)

[More]

ColdFire 1.2.117.126 (and 1.2.117.117)

Release 1.2.117.126

Last night I released a new version of ColdFire, 1.2.117.126. This is an extension only bug fix release which:

  • fixed issues with execution times tab summary rows (issues 42 and 44)
  • fixed issue with variables tab (issue 43)
  • improved multiple tab support.

Release 1.2.117.117

I also realized I never announced the previous 1.2.117.117 release on this blog. That release had quite a few improvements and new features which I'll detail below.

[More]

JSONUtil Now in RIAForge SVN

Just a quick post to let folks know the code and unit tests for JSONUtil are now in SVN at RIAForge.

Introducing JSONUtil

After getting into another discussion last week about the problems with Serialize/DeserializeJSON and ColdFusion's implicit type conversion I decided to try to do something about it. Over the weekend I put together a proof of concept which I've released as JSONUtil. From the RIAForge project site:

The JSONUtil project has two goals: to provide JSON serialization and deserialization methods for CFMX 7 which are compatible with ColdFusion 8's Serialize/DeserializeJSON functions and to provide better mapping between CF/Java/SQL data types and JavaScript data types than ColdFusion 8's SerializeJSON function.

The JSONUtil project currently consists of the JSONUtil component. This component has two public methods, serialize and deserialize, which have method signatures similar to ColdFuison 8's built in Serialize/DeserializeJSON functions. The JSONUtil deserialize method takes the same parameters as DeserializeJSON, JSONVar and strictMapping, and should produce the same results as that function. The JSONUtil serialize method takes the var and serializeQueryByColumns parameters, just as ColdFusion 8's built in SerializeJSON function, however this method also takes an optional third parameter, strictMapping. If the strictMapping parameter is ignored the serialize method should produce the same results as ColdFusion 8's built in SerializeJSON function. If the Boolean strictMapping parameter is set to true then the serialize method attempts to convert the ColdFusion data to a JSON string using underlying Java/SQL data types as opposed to using ColdFusion's implicit type conversion conventions.

The code for the JSONUtil component is based on that of the json.cfc from the CFJSON project, http://www.epiphantastic.com/cfjson. This project probably would not have happened were it not for CFJSON. Thank you to Jehiah Czebotar, Thomas Messier, and everyone who has contributed to the CFJSON project.

To expand on the RIAForge description a bit further, the strictMapping attribute I've added to the serialize method forces the CF data to be serialized based on it's underlying Java data type. For example the following code:

<cfset JSONUtil = CreateObject("component","JSONUtil") />
<cfset x = "123" />
<cfoutput> #JSONUtil.serialize(var=x, strictMapping=true)# </cfoutput>

will produce the following JSON string:

"123"

SerializeJSON or JSONUtil.serialize without the strictMapping attribute will produce the following JSON string:

123

Note the lack of quotes, indicating a JavaScript number as opposed to a string.

The strictMapping attribute also applies to query data as well. If you have a varchar column, its data will always be serialized as string data, even if the string is a numeric or Boolean value in ColdFusion. The strictMapping option also allows you to use JavaCast to help ensure your data values are serialized properly.

There is, however, one caveat to the strictMapping option. In ColdFusion most values are stored as strings. This means that both x and y below:

<cfset x = "123" />
<cfset y = 123 />

will be serialized as:

"123"

If you want numeric values to be serialized as such when using strictMapping you will need to use the Val or JavaCast functions:

<cfset x = Val(123) />
<cfset y = JavaCast("int",123) />

(Note: you do not need to do this for query values as query columns are automatically cast to the appropriate Java type by JSONUtil.)

So head over to RIAForge and check it out, and be sure to report any issues via the bug tracker.

Thanks again to the CFJSON project, and thanks to Todd Sharp for pointing out that you can get column data types from a CF query using GetMetadata().

Installing 64 Bit CF 8.0.1 on Mac OS X 10.5.5

After attending a MegaLab at MAX I decided to re-install my local development version of CF so that I could install LiveCycle ES. I uninstalled CF 8 and then attempted a re-install, only to find the 64 bit CF 8.0.1 installer doesn't play well with the latest installation of Java on OS 10.5.5. After some unproductive googling someone on the Adobe forums pointed me to this post on Paul Marcotte's blog. In the comments of that post Rich Leach posted the following instructions to get the installer to work:

  1. In a terminal window, go to /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Commands (cd /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Commands)
  2. Remove the symlinks (sudo rm -rf *)
  3. Copy the files from /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home/bin to /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Commands (sudo cp ../Home/bin/* .)
  4. Run the CF installer
  5. Remove the files from /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK (sudo rm -rf *)
  6. Recreate the symlinks deleted in step 2 (sudo ln -s ../Home/bin/* .)

I don't usually re-post content from other blogs, but this one has been bothering me for a couple of days so I thought I'd help spread the answer. Maybe Adobe should put a TechNote out on this? And yes, I've already submitted a bug report.

FAQU Volume 3 Issue 1

A new issue of the Fusion Authority Quarterly Update is out now so go and get it! I just downloaded the issue and it's as jam packed as ever with great articles, including mine, Web Services and Complex Types.

ColdFire 1.2.95.100 and a CF to JSON Gotcha

A new version of ColdFire is up on RIAForge. This is an extension only update that fixes a bug related to JSON serialization/deserialization of queryparam values.

The problem was reported and fixed by Shane Bradly. He noticed that he was not seeing the SQL for some of his queries in the ColdFire Query tab. His investigation found that passing a numeric value for a text queryparam type such as cf_sql_varchar or cf_sql_char caused the following JavaScript in the ColdFire extension to fail:

[More]

More Entries

BlogCFC was created by Raymond Camden. This blog is running version 5.8.001.