Scripting a ColdFusion Application

With the release of ColdFusion 9 this past week, at MAX, we finally have full parity for cfscript with all of the cf tags. I personally prefer script when writing data access and business logic. For some it might not appear to be the sexiest feature, but I can see it making CFML much more appealing to developers from other languages.

[More]

ColdFusion Ajax and ExtJs Presentation Update

I've been asked to present to the KCDevCore on ColdFusion 9 Ajax and ExtJs. This will be an updated version of my ColdFusion Ajax presentation, with new content to cover the updates and new components presented in ColdFusion 9 and ExtJs 3.0. By request, I'm going to try to keep the slides to a minimum and get down to some code.

That presentation will be next Tuesday, September 29th, at 7 PM CDT, and will be available via the KCDevCore Adobe Connect.

For those who don't know (where have you been?), ColdFusion 9 is now in public beta on Adobe Labs.

ColdFusion for the Redmond Crowd

Some time back I started receiving Visual Studio Magazine. I'm not sure why. I didn't request it, and lord knows I've tried to stay away long enough (since the VB6 days). But, being a developer with a background in linguistics, I began to read through the issues. C# looks interesting, and I'll probably play with it some, but for the most part all of it just reminds me why I'm a ColdFusion developer with skills in related web type languages (XHTML, CSS, JavaScript, etc).

Last week I received my August issue of VSM, and took a look when I got a chance. I got a number of surprises with this issue, the first one being the biggest. In the front of magazine is an 'Online Contents' section, where they list articles that are only available on the web from three Redmond Developer Network sites: Visual Studio Magazine, Redmond Developer News, and Application Development Trends. And, to my surprise, under the articles on ADT, the first heading read Adobe Releases First Beta of ColdFusion 9.

Now, here's a magazine dedicated to .NET development, pointing to sites dedicated to .NET development, highlighting an article about ColdFusion. Nice! This was obviously part of the interview blitz that Adam Lehman did just before the public release. The article talks about ColdFusion Builder, quotes the recent Gartner Report, and talks about the great new features in ColdFusion 9, with emphasis on Hibernate, full scripted dev support, as well as the Office and Sharpoint integration features (it also reminds readers about the .NET and Exchange integration features added in to CF 8.)

So, it was truly cool to see CF getting some love from the press. More so, being as the press targets a different developer market. But, it got cooler for Adobe with the rest of the issue. See, this issue of VSM was also the 2009 VSM Readers Choice Awards. Adobe took a few honors in several categories:

  • Help Authoring: Readers Choice Award Winner : RoboHelp and RoboHelp Server - Adobe Systems, Inc.
  • Web Design & Development Tools : Readers Choice Award Winner : Dreamweaver - Adobe Systems, Inc.
  • Web Design & Development Tools : Readers Choice Merit Award Winner : Creative Suite 4 - Adobe Systms, Inc.
  • Web & Mobile Development : Editors Choice Award Winner : Dreamweaver - Adobe Systems, Inc.

Great news for Adobe, and a nice shot over the MS bow. Looking over the other categories, I see potential with the release of ColdFusion 9. Here's some nice goals/targets for our favorite server:

  • Charting and Multimedia (should've been Flex hands down, but CF has it's own)
  • Data Editing, Reporting & Analysis Tools
  • Grid Components: Web (I can see it)
  • Imaging and Graphics
  • Middleware & Server Based Tools
  • PDF Tools
  • SharePoint Components & Tooling
  • Editors Choice: Most Valuable Tool
  • Editors Choice: Data Handling & Development

Thanks Adam, for pushing the tech press in areas that haven't historically gotten our message. Congrats to Adobe for it's new honors, and here's to hoping other dev communities begin to see, and recognize, the value of ColdFusion.

Request vs Variables - Which is right?

Last week I stirred the pot a bit, stating that we've been improperly using the VARIABLES scope, and it's hurting our applications. Variables placed within the VARIABLES scope do not appear to have proper Garbage Collection performed on them when we're done with them, except in the case of the scope's usage within a CFC or a custom tag. This brought up some interesting discussion, where Ray Camden, Mike Brunt, and others chimed in.

I, with very good success, have been using REQUEST where most people use the VARIABLES scope. Wait! Hold on! You have to let me finish first before you get bent. What I said was that, in the past, we placed variables into the VARIABLES scope within our base request templates, with no way of clearing those variables at the end of the request (if using Application.cfc). My thought is, if VARIABLES have no true (apparent) mechanism for release, in context of variables scoped this way in a base request, then they don't really belong in the VARIABLES scope, but rather in the REQUEST scope.

This was met with some push back. The first argument was that this breaks encapsulation. I want to begin my response here by saying the first obvious thing that comes to mind: ColdFusion is not OO! Sure, your ColdFusion application can be written in an OO fashion, but ultimately it doesn't have to be. There are even some who seem that think that maybe it shouldn't be. All of that being said, I agree with OO principles, and think that proper encapsulation is very important when developing your applications, especially in terms of portability and reuse. Just because the REQUEST scope can be used directly within your custom tags or CFC's doesn't mean that you should. I would never suggest referencing the REQUEST scope directly within a CFC, with the exception of Application.cfc itself.

So another argument was that the REQUEST scope should only be used "when (and only when) the variable must be accessible to all the elements composing the request...", going further to state that the REQUEST scope should be avoided if at all possible. Why? The rest of the argument once again comes back to encapsulation. My point is to use the REQUEST scope within the context of a request, paying attention to maintain encapsulation. Within that context, doesn't it make sense to use the REQUEST scope for variables that should only exist for the length of a request?

The ColdFusion Jedi piped in to correct me on my timeline of scope introductions to ColdFusion, and we had some back and forth over declaration of scope to clearing of scope. I contended that onApplicationEnd() cleared the APPLICATION scope, that onSessiondEnd() cleared the SESSION scope, and that onRequestEnd() cleared the REQUEST scope. Ray reminded me that Application.cfc was about application process, and that the server handled when to 'clear' variables 'under the hood.' My point back was that something has to tell the server when to de-reference these variables, and that I had always assumed that was triggered by the execution of these methods. Mike Brunt chimed in on this, saying that the application must de-reference the variables prior to the server knowing it can perform Garbage Collection on them (Side Note: he didn't come out and agree with all of my conclusions here, only seeming to agree with the logic applied.)

Possibly the largest argument overall relates to whether the apparent memory leak, when using the VARIABLES scope within a base request, is really a leak or just a byproduct? I've theorized that the intention of the VARIABLES scope was that it was to be used only within CFC's and custom tags, where it does appear to properly get de-referenced. I put out there that the only reason you were able to use VARIABLES within the base request was because custom tags were created from .cfm files as well, so there really isn't any way to restrict it's usage. Ray says that the VARIABLES scope was introduced to provide access (like StructKeyExists()) to the unscoped variables out there in the wild.I think our thoughts of 'best practice' usage should follow these lines: Using the REQUEST scope within the base request, while maintaining encapsulation.

Ultimately, I just don't know. Maybe there's still an Adobe engineer out there who goes back that far, and can remember exactly what's what and why. I do know that, after migrating several high traffic applications to these guidelines I did get a higher return on application performance. I've gotten notes from others, after reading the original post, who have done similar changes to their systems with the same improvements. What other pluses or minuses do you, dear reader, think of when considering this practice of variable scoping? Is it right? Is it wrong? Is it a sin? What do you say?

(You can follow the original comment thread by referencing the post linked below)

Scope Usage and Application Scaling

Mike Brunt has posted an excellent article called Good Practices For Scaling ColdFusion Applications, in which he speaks about the importance of memory management within ColdFusion applications, and calls out certain avenues of scope usage that every CF developer should pay attention too.

Great post Mike! Another 'scope' issue that I've often seen (and abused myself) is the misuse of the VARIABLES scope. Back in the early days of CF, every example you saw showed an unscoped variable, placing it into the VARIABLES scope by default. This was fine, back then, as your view layers primarily consisted of Custom Tags. Use of the VARIABLES scope, within a custom tag, was permissable as those variables were then only available within that tag (or within a nested tag, if the nested tag used the CALLER scope). Once execution of the tag was completed, the memory space of those variables was cleared.

But, since custom tags were made from .cfm templates, there is no constraint within CFML from placing VARIABLES scoped variables within any .cfm template. This, in itself, is bad, as the VARIABLES scope (in the case of a base template, not a custom tag) is not properly cleared from memory space.

What I find people doing (and I've done it myself) is using the VARIABLES scope in place of the REQUEST scope. Memory allocated to REQUEST variables is properly recovered at the end of a request. Although variables in the VARIABLES scope are no longer available (except within a persistent CFC), their memory isn't properly released at the end of request execution. (For more information on this, see Jason Sheedy's post on the ColdFusion Memory Leak, and the accompanying comment thread and other referenced posts.)

A technique that some used, to get around this issue, was to have a StructClear(VARIABLES) statement as the last line of their onRequestEnd.cfm. This would explicitly clear out the VARIABLES scope at the end of a request. But, with the advent of Application.cfc, this no longer became an option (if you use Application.cfc.) If you tried to use that statement within the onRequestEnd() method of Application.cfc, you would only be clearing the VARIABLES scope of the CFC itself, and not the request.

That's actually a good pointer at the true underlying issue: proper scope usage. Use of the VARIABLES scope within a CFC makes variables within that scope only available directly by all methods of that CFC. Use of the VARIABLES scope within a custom tag makes variables within that scope only available within that tag (or a nested tag using the CALLER scope to access them.) Within a custom tag, you can not access variables of the calling template's VARIABLES scope, unless you use the CALLER scope to do so (which should only be in the case of a nested custom tag). You can, however, access REQUEST variables through out the request, from within a custom tag, an include file, or even within a CFC (though I wouldn't suggest doing that one.) By confining the usage of the VARIABLES scope to within custom tags and CFC's, and properly setting request level variables within the REQUEST scope, you could better manage your memory usage and application performance.

I've personally seen major differences in application performance, both through Mike's advice on persistent scope usage, as well as what I've outlined above. Unlike Jason Sheedy though, I'm not very familiar with Java profiling tools, so I'll have to leave it up to someone else to test all of this for the scientific proof. I only know that it appears my applications are running better as I migrate them to this paradigm. What are your thoughts?

*** Post Revision 080609: 2230 hrs *** More revision to my comments than the post itself, but Ray, the ColdFusion Jedi himself, corrected me. According to Ray, the VARIABLES scope wasn't added until CFMX, so my supposition on the 'intention' of the VARIABLES scope was incorrect. You really have to read the comment thread to see the fun we're having;) Hopefully we'll find an answer. Cutter

CFQueryReader v1.2 - Critical Update Supporting ExtJS 3.x

I have updated CFQueryReader, addressing issues that had arisen with new builds of ExtJs 3.x. This new build should cover sporadic issues with loading a new Ext.data.Store. There is also a simple example of using Aaron Conran's DirectCFM Ext.Direct ColdFusion API stack.

The CFQueryReader Example Site has been updated as well. You can update CFQueryReader from RIAForge.

Ext Js 3.0 is Finally Released!

Yes, Ext Js 3.0 has finally arrived! This long awaited update to the popular library has finally hit the download page as a production ready build (though the Release Candidates have been pretty stable as it is). There are many great enhancements to Ext, including an even more consistent underlying model (how could it get more consistent?), and some exciting new data marshalling features.

A quick perusal of the updated Samples & Demos page gives us immediate insight into some of the new features that are available:

There's a lot more that you'll have to dig to see, like improved browser support, a better container model, and (experimental) ARIA support (for accessabiltiy). Some of the greatest enhancements come in the way of the data marshalling capabilities added via the new Ext Direct. With Direct, Ext is providing the remoting specifications so that anyone can write data marshalling services around their favorite backend language. Ext has even published Example Server Side Stacks as a jumping off point to beginning with data marshalling via Direct. [Side Note: Aaron Conran, the team lead on the Ext Js team, is a long time ColdFusion guy, and he wrote the example CF stack.) By configuring your Direct API, you can utilize data readers and writers (they're new!) easily, even passing multiple requests within a single Ajax request. [Another Side Note: CFQueryReader is fully functional with and without Direct.]

One of the nicest features of this release is the backwards compatability. There are little to few changes that most will have to make, to upgrade their applications from 2.x to 3.0. And, it was announced, on a recent User Group Tour stop, that Adobe is including Ext Js 3.0 in ColdFusion 9. This opens up the possability of some very nice, new CFAjax components to come.

All in all a fantastic release. I've had the opportunity to play with 3.0 for a while now, watching the SVN updates daily, and my hat's off to the Ext Js crew for another excellent release.

ColdFusion PreRelease Tour Coming to Nashville

NCFUG CF Tour

Greg Wilson, Adobe Platform Evangelist, is coming to Nashville to give us a sneak peak at ColdFusion 9, Codename: Centaur, and Bolt, the new ColdFusion IDE. According to various posts from cf.Objective, and other tour dates, there appear to be some major enhancements in integration capabilities, Flex and AIR interaction, and more. You don't want to miss out on this special event, giving you the inside scoop!

Click on the link above to register.

Ext JS 3.0 RC2 Released

The Ext JS team has announced the release of 3.0 RC2. This latest Release Candidate is considered to be very stable, with many new examples to show you how to do what you need to do. From someone that updates from the repository every day, I can tell you that these guys have been working hard to get 3.0 ready for full release, and there's a ton of new material there (in the examples) to learn from.

Placement of the PagingToolbar on a Grid

This morning I found I was courtesy copied by Ray Camden, on a reply that he was making to a message he had received from his Blog Contact form from Mike Knox. Mike was trying to find out if it was possible to place the PagingToolbar, used in cfgrid, at the top of the grid rather than the bottom. Ray had told Mike that he had Googled it and not found on obvious solution, and that he was CCing me for my feedback.

Like any padawan, it's pretty humbling for me to be asked advice from the Jedi Master. I've been taking Ray's advice on ColdFusion since the 4.x days, so I try to be pretty diligent when he includes me in helping others with their queries.

I've always held that the use of the CF Ajax components are primarily for rapid application prototyping. They are fantastic for putting up some very basic functionality, but when you need more advanced configuration it is then time to dig in, and go straight to Ext JS itself. Mike's question is a prime example of this. We have nearly no control over a cfgrid's configuration prior to render, and the configuration options that we do have (through the cfgrid and cfgridcolumn attributes) barely scratch the surface to what one can do with an Ext Grid. The PagingToolbar is a class object of Ext and, as such, you should be able to add it to any toolbar of a grid: top, bottom, or both. I fired up Eclipse, booted up my CF and Apache, and pulled up the Ext examples from my local copy of the latest 3.0 download. All of the examples that you can see in the Samples & Demos section of the Ext site are given to you in the download of the library, so that you can run them locally and pick them apart. So, my quest was on.

I went to the Paging Grid Example, and examined the source code of the paging.js file. I quickly found the configuration object for the paging toolbar:

view plain print about
1var pagingBar = new Ext.PagingToolbar({
2 pageSize: 25,
3 store: store,
4 displayInfo: true,
5 displayMsg: 'Displaying topics {0} - {1} of {2}',
6 emptyMsg: "No topics to display",
7
8 items:[
9 '-', {
10 pressed: true,
11 enableToggle:true,
12 text: 'Show Preview',
13 cls: 'x-btn-text-icon details',
14 toggleHandler: function(btn, pressed){
15 var view = grid.getView();
16 view.showPreview = pressed;
17 view.refresh();
18 }
19 }]
20 });

The PagingToolbar instance is then applied to the Grid, placing the object in the 'bbar' (bottom bar) attribute:

view plain print about
1// paging bar on the bottom
2 bbar: pagingBar

After seeing this in the online demo, I went to my local (3.0) demo to see if I could change it. The Ext team rewrote the demo for the upcoming 3.0 release, placing the instance initialization directly in the attribute:

view plain print about
1// paging bar on the bottom
2 bbar: new Ext.PagingToolbar({
3 pageSize: 25,
4 store: store,
5 displayInfo: true,
6 displayMsg: 'Displaying topics {0} - {1} of {2}',
7 emptyMsg: "No topics to display",
8 items:[
9 '-', {
10 pressed: true,
11 enableToggle:true,
12 text: 'Show Preview',
13 cls: 'x-btn-text-icon details',
14 toggleHandler: function(btn, pressed){
15 var view = grid.getView();
16 view.showPreview = pressed;
17 view.refresh();
18 }
19 }]
20 })

So, I changed 'bbar' to 'tbar' (top bar) and reloaded the page. Success! The PagingToolbar was now in the top toolbar of the Grid, and fully functional. After reviewing all of this, I decided to go a step further. Could you have two separate PagingToolbar configs on the grid? One at the top and one at the bottom? So, I tried this:

view plain print about
1// paging bar on the bottom
2 bbar: new Ext.PagingToolbar({
3 pageSize: 25,
4 store: store,
5 displayInfo: true,
6 displayMsg: 'Displaying topics {0} - {1} of {2}',
7 emptyMsg: "No topics to display",
8 items:[
9 '-', {
10 pressed: true,
11 enableToggle:true,
12 text: 'Show Preview',
13 cls: 'x-btn-text-icon details',
14 toggleHandler: function(btn, pressed){
15 var view = grid.getView();
16 view.showPreview = pressed;
17 view.refresh();
18 }
19 }]
20 }),
21 // paging bar on the top
22 tbar: new Ext.PagingToolbar({
23 pageSize: 25,
24 store: store,
25 displayInfo: true,
26 displayMsg: 'Displaying topics {0} - {1} of {2}',
27 emptyMsg: "No topics to display",
28 items:[
29 '-', {
30 pressed: true,
31 enableToggle:true,
32 text: 'Show Preview',
33 cls: 'x-btn-text-icon details',
34 toggleHandler: function(btn, pressed){
35 var view = grid.getView();
36 view.showPreview = pressed;
37 view.refresh();
38 }
39 }]
40 })

That's part of what I love about development, I get to play, experiment, have some (geek) fun. After refreshing the page, I now had two toolbars, at both the top and bottom of the page. Both worked perfectly, and stayed in sync during paging. That's what I love about the Jack Slocum and the Ext Team, they think about things like having more than one paging bar and how they would need to stay in sync, and they've already written it in to the library.

And so, on rare occasion, the student has the opportunity to become the master, though I'm sure there's still plenty more I can learn from Master Camden;)

Previous Entries / More Entries