Yesterday a friend on twitter was upset by the fact there was no CFWDDX support within ColdFusion scripting. This got me thinking other things not yet supported and ways that developers can work around them. While scripting has gotten very close to being "100% complete" under ColdFusion 901, there are definitely a few things left you still cannot do (WDDX being one of them) and I thought a discussion about ho to handle that might be nice.
First though - remember that it can sometimes be difficult to see what is supported in scripting because some features aren't listed where you might expect them to be. Consider "try", as in cftry. If you look in the CFML Reference you will find documentation for cftry but see no mention of how to use try within script. You may be included to check the function listing, but it is not there. That's because the try command is a keyword, not a function. You can find a good list of these keywords in the documentation within the Developer's Guide: What is supported in CFScript. Unfortunately this page doesn't tell you how to use these keywords. So for example - consider cflocation. Here is an example of how it is used:
location(url=group.getHomeUrl(),addtoken=false);
That's nice - but on the flip side, include, the script equivalent of cfinclude, works like so:
include "render/blogpaneledit.cfm";
These are kind of documented here: Using system level functions But there is no mention of include, or try for that matter.
So that's keywords, but then you also things that are supported via new components. These components may be found in cfinstall\customtags\com\adobe\coldfusion. A documented list may be found here: Script Functions added in ColdFusion 9. These are detailed in the Reference: Script Functions Implemented as CFCs. Be sure to notice the link to the enhancements in 901: Script functions implemented as CFCs in ColdFusion 9 Update 1.
Speaking of 901, don't forget that support for handling file uploads, via fileUpload, as well as directory commands, were added in 901. These were both things that forced me to use tag based CFCs at times in CF9.
Ok - so I said this blog entry was about workarounds for things not supported. Hopefully though you check these docs first to ensure that what you want to do is actually impossible. I've used a few different workarounds in my development and at work. Here are a few examples.
- What about cfsetting?
cfsetting has a few different options in it, but the one we use mostly is showdebugoutput="false". This is critical for pages that may serve up JSON or XML to remote clients. Unfortunately this is not possible to do in scripting. In the past, I've seen this workaround used:
include "setting_debug.cfm";
The file, setting_debug.cfm, will have a grand total of one line - a tag based cfsetting. That kinda sucks. But it also means the calling CFC can stay in script. Since you typically only need one of these, the one hack by itself isn't so bad.
- What about tags like wddx, etc, not supported?
You have a few options. For something like WDDX, it wouldn't take very long to write a UDF "wrapper" for the tag that handles serializing and deserializing WDDX strings. Once done, you can include this into your script based CFC or inject it like a service via your favorite dependency injection tool. This is the route I took for Adobe Groups and file uploads. I wrote Adobe Groups when CF9 was released. I had a few services that needed file operations, like uploading processing, so I simply wrote one tag based CFC to handle all file operations. It was a simple utility component that other services (fancy script based ones) could easily make use of. This wouldn't be necessary in 901.
Another route is to go the component route. Consider that cffeed was added in 901 as a component and not a new function. Unlike WDDX support, RSS parsing is somewhat more complex. Therefore it makes since to have a CFC/object based type approach to handle it. I helped write this component for Adobe. The code in that folder is all unencrypted and follows a standard style that you could mimic yourself. That's exactly what I did. I looked at Adobe's code for the other CFCs, wrote the feed support, and just stored it in the same directory. This gave me feed support in CF9. When 901 was released, I just removed my version.
Finally - don't forget you can file an enhancement request for things like this (script based version of cfwddx). If Adobe doesn't know that this is important to you, it won't be very high on their list of things to work on. The more you document, and vote, the easier it gets for Adobe to prioritize development.