For those of you who wanted my slides from my presentation at NCDevCon — Improving Application Performance with 3 Simple Functions — they're attached to this post. As usual, I learned a lot about what would work and would not work while practicing this presentation, and was making changes just an hour before showtime. I received some good feedback from a couple of people in the session as well, and wanted to extend my thanks to everyone who attended the session,

NCDevCon has turned out to be a really good conference with a number of interesting sessions. A couple of sessions that I wanted to see are running concurrently, which is bad for me but, I think, always the sign of a good conference!

A few months back, we moved all of our user-generated content to a file share, and had to rewrite some of our code to use the new UNC path to the files. As with most things ColdFusion, it's best to let the application server do the hard work for you, so instead of writing out the full UNC path to files in a <cffile> tag, you should use the expandPath() function instead. This is a really good idea if, at some imaginary point in the future, the path to your file share changes. (File shares never change locations in a network, right?)

One thing that tripped me up on more than one occasion was the need to run expandPath() on the directory that points to the file share, and not another directory like webroot or wherever you might be storing files on the actual ColdFusion server. So instead of doing this:

you have to do this:

Otherwise, ColdFusion won't be able to resolve the actual path to the file share directory via the appropriate UNC path. It will look for a directory called "fileShareDirectory" in the webroot, even if there's an alias set up at the operating system level to point to the actual file share on another server.

Although I've spoken at a number of conferences in the past decade, and at three educational technology conferences in the last year, I've never spoken at a ColdFusion-specific conference. That's about to change. Both the NCDevCon team and Ray Camden and the team behind the CF Unconference at MAX have given me the opportunity to finally do so.

Here's the description of the talk that I submitted to both conferences as part of my topic proposal:

Title: Improving Application Performance with 3 Simple Functions

Using three, new, simple functions introduced in Adobe ColdFusion 9 -- cacheGet, cachePut, and cacheRemove -- you can significantly improve the performance of your Web-based application. In this session, we'll look at concrete examples of where utilizing the new object-based caching functionality of Adobe ColdFusion 9 can shave seconds (or more) off of each request. The following specific scenarios will be covered:

• populating customer information in session objects
• creating heavily composed objects
• pulling and processing data from external sources/third-party APIs
• building complex queries outside of the database server
• building report tables

This session won't cover the powerful extensibility of Ehcache, the technology behind these caching functions, and is targeted towards developers who haven't utilized application server caching before.

I plan on using code examples from a pretty big production application for which my team is responsible.

The final schedule for NCDevCon hasn't yet been set, but I'll post my session information as soon as I know it.

For the CFUnconference, I'm speaking on Wednesday, October 5 at 10am.

There are some other sessions on caching at the CF Unconference, but I hope what distinguishes mine is the focus on application development and code and the target audience of intermediate ColdFusion developers who have never used caching before, rather than the big picture on Ehcache and Ehcache administration.

Check out the Lanyrd site for the CF Unconference to see the whole unconference schedule, and to see who else is involved and attending.

When we were putting together the MachBuilder extension for ColdFusion Builder 2, Kurt Wiersma and I ran into a major roadblock: we couldn't add any features to the extension that operated on Mach-II configuration files because ColdFusion Builder 2 extensions only work on CFC and CFM files. If you want to see ColdFusion Builder extensions work on XML files in future releases of ColdFusion Builder, please vote for this feature. However, if you install the Eclipse Web Tools Project (WTP) XML editor and correctly point to the DTD for the Mach-II XML configuration file, you'll get code completion and assist in your configuration files.

While simply pointing to the correct DTD should work in pretty much any XML editor that you add to Eclipse, the standalone version of ColdFusion Builder 2 (and ColdFusion Builder 1) incudes Aptana Studio's XML editor, which doesn't provide code completion or assist. If you installed ColdFusion Builder 1 or 2 into an existing Eclipse install, you may already have an XML editor which you can use. Even so, a lot of people speak highly of the features of the WTP XML editor.

Note that this works for ColdFusion Builder 1, ColdFusion Builder 2, and CFEclipse.

ColdFusion Builder 2 is built upon the Helios release of Eclipse. You'll first need to add the generic Helios update site to your install in order to get the correct files. (If you're using the Galileo release of Eclipse (which is what ColdFusion Builder 1 was built upon), you'll need to add the Galileo update site instead.)

Here's how you get it all working:

1. From the "Help" menu, select "Install New Software..."
2. Add the top of the "Available Software" window that appears, click "Add" next to "Work with:"
3. In the "Add" window, enter "Helios Update Site" for the name and http://download.eclipse.org/releases/helios/ as the URL.
4. Click OK
5. Eclipse will now make a remote call to the Helios Update Site and present you with a list of software that's available.
6. Open the disclosure triangle next to "Web, XML, and Java EE Development"
7. Select "Eclipse XML Editors and Tools"
8. Click "Next" at the bottom of the "Available Software" window, "Next" again to get past the details page, and finally "Finish" once you accept the license agreement.

One the install has finished and you've restarted ColdFusion Builder/Eclipse, you need to open your Mach-II XML configuration file and make sure you're pointing to the correct DTD to actually get code completion and assist working. There are details on how to do this on the Mach-II Trac.

Essentially you just need to put the correct DTD at the top of your Mach-II XML configuration file, right after the opening XML tag. If you're using Mach-II 1.8.1 (the latest stable release), that declaration would be:

One final and very important step: you have to open the Mach-II config XML file with the WST XML editor, not the default ColdFusion Builder XML editor. If you double-click the XML file, it opens in the default ColdFusion Builder XML editor. To do this, right-click on the file and select "Open With..." and then "XML Editor" (which is the Eclipse WST XML Editor).

The WST XML Editor has two modes: design and source. When you open an XML file, it defaults in to the design view. You more than likely want to click the tab at the bottom of the XML code editor window that switches to the source view. Once in that view, you can get code assist by hovering over items in the XML file and code completion by simply typing.

Thanks to Peter J. Farrell and Kurt Wiersma for pointing me in the right direction to get this working.

I blogged earlier this month that ColdFusion Builder 2 ships with a number of extensions for the major ColdFusion frameworks. MachBuilder is the extension for the Mach-II framework, and was built by Kurt Wiersma and I.

The extension ships with ColdFusion Builder 2 and can be found in the "extensions" folder inside in the ColdFusion Builder 2 install directory. You can also get it as part of the core Mach-II 1.9 download.

MachBuilder currently has two major features:

1. Configure and create a new Mach-II application skeleton

This option is available to you when you right-click on a project folder or a folder within a project. Selecting this option brings up a simple form that provides you some configuration options for a new Mach-II app skeleton. This includes:

• Specify the application name
• Specify the event parameter name
• Enabling the ColdSpring property
• Enabling SES URL writing in the Mach-II app
• Enabling the on-screen Mach-II logger
• Providing the password for the Mach-II Dashboard
• Specify a custom webroot path if you don't want to use the default

When you tell the extension to create the application skeleton, it parses through the application sekeleton files and inserts the values that you enetered as required. If you wanted the ColdSpring property to be set up, it does that for you. The same goes for SES URL rewriting (using the default /key/value/ pattern), and the logger. The Dashboard is included by default, as it's part of the core Mach-II 1.9 framework. If you don't want to include the Dashboard, you can delete the related lines from the mach-ii.xml configuration file.

All of the files end up in the folder which you right-clicked on to fire off the extension. You'll want to make sure that you're running the extension in the correct folder. If you want the Mach-II application skeleton files to be put into your webroot, then right-click on your webroot folder. If you want the application to live inside a folder in your webroot, right-click on that specific folder.

2. Display Mach-II Dashboard

This option is only available when you click on files in a project. It does one thing: launch the incredibly useful Mach-II Dashboard for the currently selected server in a view inside of ColdFusion Builder. That view stays open, like all ColdFusion Builder 2 extensions that create views, until you either close it or quit out of ColdFusion Builder 2.

The Mach-II Dashboard is what I would consider to be a required tool in developing Mach-II applications. If you're not using it and you develop using Mach-II, you're missing out on significantly improved development.

We had hoped to provide code assist on Mach-II configuration XML files with this extension, but ColdFusion Builder extensions currently do not work on non-cfc/cfm files. The ColdFusion Builder team is aware of this issue, but if you want to make sure that this becomes possible in the next version of ColdFusion Builder, then please vote for this enhancement request!

Side note: You can get code hinting and assistance on your Mach-II configuration XML files if you use the Mach-II DTD and the free Eclipse Web Tools Project (WTP) XML editor (not Aptana, which is the default XML editor in ColdFusion Builder).

One other feature of this extension is that it will automatically notify you when there's an update to the extension. (Kurt spent a lot of time for this 1.0 release implementing the auto-update mechanism.) We plan on adding more features to it in the future (see this Google Doc for more), and you're encouraged to add feature requests to the Mach-II Trac site. Mach-II is community-driven, after all.

If you want to see how this extension works, including the callback to refresh the Eclipse project view when creating a new Mach-II project, look at the "Mach II Builder Extension" directory that gets created in your webroot when you install the extension into CFBuilder.

In all the coverage of ColdFusion Builder 2, one thing that hasn't been mentioned is that the IDE now ships with a bunch of framework-specific extensions. There are extensions for:

• Mach-II
• ColdBox
• Model-Glue
• CFWheels

Each of the extensions provides functionality for building apps with that framework. Each extension has different functionality, but if you're using one of those extensions, you should find that it makes you more productive (or at least we certainly hope it does!).

These extensions can be found in the CFBuilder Install Directory/extensions.

I helped write the MachBuilder extension for Mach-II. The super-smart Kurt Wiersma did most of the work, but my contribution to the project was doing the Mach-II application skeleton work.

I'll detail the MachBuilder extension in a future blog post, but the key thing to remember is that these extensions do exist for the major CF frameworks. Use them — or contribute to making them better!

One of the really great new features of ColdFusion Builder 2 is the ability to create brand-new views in Eclipse from a CFBuilder 2 extension. This opens up a whole host of possibilities for developing with ColdFusion.

Here's a quick example of how this can be really useful: say you want to have a way to quickly access the ColdFusion server administrator on your localhost from within CFBuilder. Sure, you can ALT-Tab to switch to Firefox/Safari/Chrome and pull up the administrator, but wouldn't it be nice to not have to leave your IDE? With extensions in CFBuilder 2, it's really easy.

Attached to this post is a .zip file of a simple ColdFusion Builder 2 extension that does just this. I'm not going to go over the basics of extensions — you can read the docs or just Google that. Instead, I'm going to focus on the parts of the extension directly related to creating a new view in Eclipse.

In the ide_config.xml file for the extension (which sets up the basic configuration for the extension), I tell CFBuilder that I want a new menu item in the project view. Any time I right-click in the project view, "Open CFAdmin on Localhost" will appear as a menu item. I also tell CFBuilder to run openview.cfm when this menu item is selected.

openview.cfm is really simple. Here's the entirety of the file and the new CFBuilder 2 magic:

All that happens here is we set the content type to text/xml so that CFBuilder can parse the response, and then in the <response> tag, I tell the IDE to open a new view with an ID of "cfAdmin," label it "CF Admin on Localhost" and then give it the URL of the CF administrator on my local server. The <ide> <view> <ide> block is what makes this happen. 3 lines of code is all it takes to create a new view in Eclipse using CFBuilder 2. Try that with native Java code.

There are other ways of generating views in Eclipse using CFBuilder 2, and you should read the docs to find out the what those other methods bring to the table. In the meantime, you now know how simple it is to create a new view in Eclipse using a CFBuilder extension. You can bring your Web-based bug tracking system into Eclipse this way, keep an eye on your GMail, or handle any number of other Web-based tasks right inside CFBuilder. Just change the URL specified in the <ide> tag and you're good to go.

One important caveat: if the URL you bring up in the Eclipse view has buttons or links that open new windows, they won't appear. There's also no support for Flash or other plug-ins. However, if the site you're bringing up requires basic HTTP authentication, CFBuilder will use your Keychain on Mac OS X to supply the required username and password. Sweet!

Finally, as the CFBuilder 2 docs note, any views that you create via extensions do not persist between restarts of CFBuilder. You'll need to open those views every time you launch the application, or as needed. Perhaps this is something Adobe can address for CFBuilder 3.

Download the CF Administrator View extension
(Requires ColdFusion Builder 2)

One of the things that I liked a lot about CFEclipse was its support for TODO tags in your code. You enter a comment like:

<!--- TODO: Clean up database call --->

And the CFEclipse parser would see that TODO string and make a task out of that comment and put that task in the Tasks view in Eclipse. This serves as a really handy way of keeping track of the small tasks you need to get done while working on a new feature for an application. It doesn't replace a dedicated ticketing and task tracking system, but it's quite useful.

For reasons I either don't remember or never learned, this feature never made its way into ColdFusion Builder 1. It was an annoyance as I used the TODO task support as part of my development workflow.

Now that the beta of ColdFusion Builder 2 is out, TODO task support has thankfully been added. By default, CFBuilder 2 makes tasks out of comments that begin with TODO or FIXME. You can add additional task types by going to Preferences > ColdFusion > Profiles > Editor > Task Tags. Open up the Tasks view (in the "View" menu), and you'll see all your TODOs and FIXMEs and REFACTORs (or whatever task tags you create) listed there.

I find that while I don't necessarily create tickets in our ticketing/tracking system for all the sub-tasks that go into creating a new feature or enhancing an existing feature, I use TODOs as a tracking system for all the sub-tasks in CFBuilder itself. This way, I can review existing code, plan out my changes using TODOs or similar tags, and then see all of the things I need to do in the Tasks view. This is especially useful when changes span multiple files.

There's a lot of new stuff in CFBuilder 2, but this is one that you can start to use with little effort and definite reward.

When I first started using CFBuilder, I missed one of the conveniences of Flex Builder: automatic closing of tags. This means that when you type <cfquery>, CFBuilder should insert a closing </cfquery> tag right away, as Flex Builder does for MXML tags.

This wasn't happening for me, and that's because the preference for doing this was turned off in my preferences. To fix this, go to:

Preferences -> ColdFusion -> Editor Profiles -> Editor -> Typing, and make sure that "Auto-close tags" is not set to "Never."

That little fix saved me a bit of time and more than a little redundant typing.

While I was reading the excellent topic "Database Development Mistakes Made by Application Developers" over on Stack Overflow, I followed a link to "What are the most common SQL anti-patterns?" and came across this tip that made me wonder if I've been handling the creation of new identity values all wrong:

• @@IDENTITY returns the last identity value generated for any table in the current session, across all scopes. You need to be careful here, since it's across scopes. You could get a value from a trigger, instead of your current statement.
• SCOPE_IDENTITY returns the last identity value generated for any table in the current session and the current scope. Generally what you want to use.

This article from a SQL Server MVP pretty much repeats that information.

Now, I don't use triggers in my application building. I prefer to have the business logic in the application layer, not the database layer. I've not run across any identity scope issues before, but that doesn't necessarily mean I'm safe, or that one of my team members won't use triggers in their application development.

If you do an insert via <cfquery> in ColdFusion 8 and 9, it returns the ID of the inserted row (or rows) in the result attribute of the <cfquery> tag. For example, if you're using SQL Server, result_name.IDENTITYCOL is the reference to the ID of the inserted row. If you're using MySQL, it's result_name.GENERATED_KEY.

Does anyone know if CF uses @@IDENTITY or SCOPE_IDENTITY()?