The Bookstore App Meets ColdFusion 8 (aka Operation: AJAX)

I've been playing with the new AJAX capabilities in ColdFusion 8, and I'm impressed. They've really made it easy to add AJAX functionality to an application. As a personal experiment, I decided to try converting an existing page-based app into a single-page, AJAX-driven one. So as usual, I brushed the dust off of my tried-and-true sample bookstore application and went to town.

Some of you might have seen the bookstore app before; I've had it on my site for quite a long time. It's gone through Fusebox 3, FuseQ, Fusebox 4, Fusebox 5, Mach-II, and Model-Glue:Unity versions. It was also the basis for my "Framework-Agnostic Models" presentation at this year's Frameworks Conference.

I was quite stunned to find that converting the Fusebox 5 version into an AJAX application took about 2 hours. Yes, 2 hours. Part of the reason it was straightforward was that the app already leveraged self-contained content blocks for each page element. Basically, each of the sidebar elements, the main page content, and the menu are all CFDIV blocks now. Each one updates on its own, asynchronously, using the built-in AJAX goodies in CF8.

It was interesting to see how my development approach had to change to support a more event-driven GUI. Each link or form is tied to a JavaScript event handler that determines which content elements to update via AJAX. I can see now how doing complex GUI programming is a real challenge, because this was only 8 or 10 events. I think I have some learning to do when it comes to patterns that apply more to GUI development than the patterns I'm used to dealing with in the model.

In any event, I've added this AJAX-ified version of the bookstore to the Framework-Agnositc Models Code and Presentation .zip file in the right sidebar. If anyone is interested in having a look, please do and let me know what you think.

Comments Comments (2) | | Digg It! Digg It! | Linking Blogs Linking Blogs | 7399 Views

Should Frameworks Prevent Cross-Site Scripting?

Someone recently posted about a Fusebox "vulnerability" which is making the rounds in some security circles. The full thread can be read here. But to save you some time (the thread is long), the issue is really that someone realized that you can perform a cross-site scripting (XSS) attack on a Fusebox site by passing some script tags into the fuseaction URL value. Note that this only works in cases where the error handler outputs the code, and where no other XSS prevention measures are in place.

Now protecting against XSS is something that all developers should already be doing as good practice. Heck, in ColdFusion 7, stopping this takes one line of code: enabling scriptProtect in Application.cfc or the cfapplication tag. Which begs the question, should Fusebox (or any framework for that matter) be responsible for filtering out things like this? Even if it was added to the framework, it should probably be disabled by default because if someone is already using scriptProtect you don't want that logic running twice. And that means that if the user has to turn it on they already know about the problem. And if they already know about the problem then couldn't they just enable scriptProtect or use one of the custom tags out there that do this? It's kind of a vicious circle. I'm interested to hear what folks think about this as it applies to Fusebox (or Mach-II or Model-Glue or onTap, for that matter).

Comments Comments (9) | | Digg It! Digg It! | Linking Blogs Linking Blogs | 6952 Views

Fusebox and Frameworks Conference

As some of you might have seen from the various mailing lists, this year's Fusebox conference has been expanded to Fusebox and Frameworks! It is taking place on 9/29/05 and 9/30/05 in Rockville, Maryland.

In addition to lots of great information and sessions on Fusebox, there will also be presentations and meetings on Mach-II, Model-Glue, Tartan, and hopefully some of the other frameworks like onTap and ColdSpring.

Unfortunately I won't be able to make it to the conference this year as I will be at a wedding in Houston during those dates, which is a shame. I presented at last year's conference and it was a great time. Not only do you get to hear speakers talk about topics of great interest, but you get to network with lots of other like-minded developers. I would recommend it to anyone with an interest in frameworks! | Digg It! Digg It! | Linking Blogs Linking Blogs | 5085 Views

CFC To Generate Fusebox Parsed Files

Well after some more work I've created a CFC that can generate parsed files for an entire Fusebox application.

You pass in an absolute path to your application root (where the Fusebox XML file lives), or a relative path from the CFC to the application root, along with the site URL. With this information, the CFC reads the Fusebox XML file, then reads all of the Circuit XML files and identifies all of the public fuseactions. It also determines the application's Fusebox password from the Fusebox XML file.

The CFC then executes CFHTTP calls to all the public fuseactions, using the Fusebox password and setting fusebox.execute=false in the URL. This way the core files create the parsed file for each fuseaction without executing it. That way you don't need to worry about passing in form or URL variables. The CFHTTP calls all happen inside a named lock so that the CFC will only use up one thread and execute one request at a time, to avoid bogging down the server.

Using it is easy:

<cfset args.appPath = "/fb41bookstore" />
<cfset args.appURL = "" />

<cfset parsedFileGenerator = createObject( 'component', 'FuseboxParsedFileGenerator' ).init( argumentCollection=args ) />
<cfset executionResults = parsedFileGenerator.generateParsedFiles() />
<cfdump var="#executionResults#" label="Parsed File Execution Results" />

The returned structure contains an array showing all of the URLs that were requested, along with the status of each request. If you want additional information, you can pass in 'debug' to the method call - generateParsedFiles( 'debug' ) - to get back some additional structure keys containing the Fusebox XML and what the CFC determined were the public fuseactions.

I've added this to our production application so that when we do a full refresh/reload of the application it also generates all the parsed files. This minimizes that "first load delay" that some users experience.

Obviously if you want to keep the CFC in a central directory, you'll have to use the right path when you invoke the CFC, as well as modify the return type of the init() method. I've included a small file showing the use of the CFC as well as documentation created with Spike's CFC documenter. I hope some Fuseboxers find this useful!

Comments Comments (3) | | Digg It! Digg It! | Linking Blogs Linking Blogs | 10741 Views

Autogenerating FB4 Parsed Files

Recently someone in the Fusebox forums was complaining about the fact that when you do an application reload, you take a performance hit the first time any fuseaction is called. This is because the fuseaction's parsed file must be regenerated and that doesn't happen until someone actually makes an HTTP request for that fuseaction. I pointed out that the performance his is relatively small and that it only happens rarely.

However, I also got to thinking that one could build a program that does this for you. Basically a program that would make HTTP calls to all the fuseactions in your application right after you do the reload. That way all the parsed files would be created and already waiting for user requests. | Digg It! Digg It! | Linking Blogs Linking Blogs | 5412 Views

More Entries