Macromedia MX related news and discussion
ColdFusion CFCs != OOP December 22, 2003

Brian LeRoux makes an observation about ColdFusion CFCs that I think is important: CFCs in ColdFusion shouldn't be thought of as a way to make CFML 100% object oriented. As far as I know, Macromedia never intended CFCs to make CFML perfect OO. That's what the Java support is for. If you want to incorporate true OOP into your CFML apps, CFCs will make a poor substitute for Java classes.

But on the other hand, with CFCs, you can get really close to OOP, and because you're using CFCs in CFML, a langauge designed around the statelessness of the web, why bother pulling in a lot of the complexity of true OOP?

Brian uses the saying in his article "When all you have is a hammer everything starts to look like a nail." I don't think the saying works here. In fact, I don't think it supports any idea at all. Is Brian suggesting that ColdFusion is a hammer, or that CFCs are? Does he use the quote to suggest that because a lot of people like to use CFCs as if they're OOP that something bad is going to happen because of that? I don't get it.

Posted by Michael Buffington at 03:25 PM in ColdFusion | Permalink | Comments (1) | TrackBack (1)
ColdFusion Thoughts on Fusebox

I gotta say, I'm a bit dissappointed in an article Kay Smoljak recently wrote for Macromedia's DevCenter talking about using the Fusebox framework to develop ColdFusion applications. While the document is short and sweet, it misses a lot of the good reasons to use Fusebox, and also leaves out some important technical details, like Exit FuseActions (XFAs). If I were a beginner considering using Fusebox, I'm not sure I'd be amped by the article.

I think what I'd like to do is pick apart Kay's article. I know, it's not entirely fair to Kay. I know the pressure of writing an article for Macromedia, and I can't ask that she write the perfect article, but I think some points of clarification could actually help support someone learning Fusebox. I'll try to go in order, quoting Kay, adding my own thoughts and probably end with some overly long summary about why I use it and like using it. Keep in mind that everything Kay talks about, as well as myself, is Fusebox 3.0 related. Fusebox 4.0 is getting off to a slow start, but Fusebox 3.0 is by far used on a much wider basis.

In regards to pushing every request through the "Fusebox", Kay said:

"The only way to execute code in a Fusebox application is to channel the request through the central fusebox."

Technically speaking, this isn't true. A Fusebox Application is a ColdFusion application, and code can be executed any way you like. Just because you're using Fusebox doesn't mean you're stuck. It's better to say that the Fusebox framework is designed to route requests through a central "Fusebox", and some of the advantages of Fusebox exist because all requests are routed through a central "Fusebox". Fusebox itself will not stop you from executing code any way you like. And the term "code execution" is pretty broad too - you can include custom tags, calls to CFCs, calls to UDFs and more, each executing in their own special way, and still have a Fusebox application. Are you better off sticking to the framework? Absolutely.

Regarding the smallest "unit" within a Fusebox application:

"A fuse is the smallest unit of code, a single file that performs a single, atomic, low-level task. This task might be querying a database, or displaying some code, or sending an e-mail, but it should not be more than one of these."

I couldn't agree more. The trouble a lot of developers get into with Fusebox is having fuses that perform too much. I've often had Fusebox applications where I have a fuse that literally has no more than a single CFIF statement, setting a flag if a certain condition is true. Simplifying fuses is of utmost importance in a Fusebox application. Don't be concerned with "too many fuses" if those fuses all perform specific and required tasks. This kind of approach isn't much different than creating a good CFC or Java class for that matter, where the methods within the CFC are as simple as possible. Simplicity opens the possibility for code reuse, and segregates instructions into managable bites.

Kay touches on the structure of a fusebox application briefly, so I'll add my own thoughts as well.

A lot of beginners to Fusebox seem to be overwhelmed by jargon, and spend more time thinking about the terms than trying to find the simplicity of it. Fusebox is indeed very simple.

I've found it easiest to think of a Fusebox application as a hierarchy, or a tree. It's nested. At your root application level/folder/directory, you have what Fusebox considers to be the "main" circuit. Subdirectories are generally considered to be sub circuits (in fact, you can't have a sub circuit unless it's within it's own directory).

In the applications I've built using Fusebox, circuits usually consist of different areas of functionality within a web application. For example, if I were developing a blog tool using Fusebox, I might seperate the application into at least three distinctive areas of functionality: blog display, blog entry management, and reporting. This would make for a simple tool, but I think you get the idea. I could create a folder within my application called "blog", one called "management", and one called "reporting" and decide that those would be Fusebox circuits. If the application itself is the biggest unit in Fusebox, circuits are the second biggest.

Within these circuits exist fuseactions. Using the blog tool as an example still, under the management circuit, I would need the ability to create a blog entry, or delete a blog entry, or add meta data to a blog entry. In any case, for each of these specific "actions", I'd create a Fuseaction to would execute my fuses. You'll remember earlier that I agreed with Kay, that fuses are the smallest units of a fusebox application, and should be as specific as possible.

So, if within our imaginary blog tool application we had a circuit within the application called "management", and a fuseaction to delete blog entries, the fuseaction itself might consist of two fuses depending on how fancy we got.

The first fuse might be a query fuse, and it might simply require a blog entry ID, and that's it. The code within the fuse would consist of just a CFQUERY tag or a CFSTOREPROC tag, and would do nothing else but delete whatever blog entry existed with an ID of whatever was passed to the fuse. You might follow that up with a second fuse that reindexed the blog's search index, or did some other kind of cleanup, or redirected you back to main blog entries list, or whatever you chose to do.

The point is, that in creating these simple fuses, then "packaging" them up in a fuseaction, a ton of useful things happen. You can reuse fuses in other circuits/fuseactions because in theory, you designed them in a pretty self sufficient/reusable manner. You can unit test individual blocks of code, creating a very robust application. It makes it very easy to work with a team of developers, because each developer can take some kind of ownership over standardized, yet specific blocks of code.

In Fusebox you tell the Fusebox framework where your circuits are within the fbx_circuits.cfm file. Within each circuit, you'll have fbx_switch.cfm, which tells the framework how you'd like to execute your fuses. The fbx_switch.cfm file is really just a single CFSWITCH statement that includes each fuse within a different CFCASE tag. I like to think of the fbx_switch.cfm file as an exact roadmap of the flow of your application. By looking at it, you should know, without a doubt, how your application will behave in the hands of a end user. If it doesn't tell you, then chances are that within your fuses you have logic that diverts application flow. If that's the case, it's best to redesign those fuses so that their purpose is obvious by looking at the fbx_switch.cfm file alone.

Kay leaves out something that I think is a big advantage of using Fusebox. Really, it's common sense, but if you're new to Fusebox you'll hang up on it. Fusebox uses something called XFAs. XFAs are a fancy way of saying "instead of hard coding links, form actions, or CFLOCATION urls, use something dynamic instead." Don't let the acronym scare you, it's truly nothing more than doing something like >a href="#xfa.myFuseaction#"<. You should set the XFAs within the fbx_switch.cfm file so that you can stick to your "roadmap" approach. XFAs make it easy to change the application flow without having to go in and edit individual fuses. It also supports the idea of making code reusable.

I know I've claimed that Fusebox 3.0 is simple, but I'll admit, I haven't covered everything here. I think it's sort of like trying to tell someone how to ride a bike who never has. You can discuss the forces of gravity, friction, transfer of energy, and bike mechanics and in the end, the best way to learn how to ride a bike is to just get on one and push on the pedals.

Continuing with the biking theme, I'll suggest that trudging through all of the documentation (especially the documentation at is sort of like me talking about drag coefficients of natural rubber bicycle tires versus tires with some composite material. It may simply be easier to find an example Fusebox application, and pick it apart.

Posted by Michael Buffington at 02:50 PM in ColdFusion | Permalink | Comments (2) | TrackBack (0)
ColdFusion CFMX Query of Query Bug December 17, 2003

I found a bug in CFMX 6.1 this afternoon.

Apparently, when doing a Query of Query against a query created using the QueryNew() function, CFMX guesses what the datatype is for each column based on the data in the first row.

So if your Query of Queries sees an integer in the first column of the first row, and then sees a string in the first column of the second row, CFMX will throw an error that says it cannot convert the datatype to another datatype.

A quick work around is to add strings to the first row when using QueryNew(), then handling it later, but that really sucks.

Macromedia really needs to get on the ball with this one, because I use QueryNew() quite often, and I'm know I'm not alone.

Posted by Michael Buffington at 05:18 PM in ColdFusion | Permalink | Comments (8) | TrackBack (0)
Dreamweaver Dreamweaver MX 2004 Demystified December 02, 2003

Dreamweaver MX 2004 Demystified is an excellent resource for web developers who use DWMX 2004, but probably shouldn't be your first choice if you're looking to make full use of the tool with ColdFusion. The writing is fresh and easy to read, written in a conversational tone that makes reading and understanding topics easy. The book is chock full of useful screenshots with clear labels, showing exactly what the text is talking about. There are plenty of useful tables and illustrations, making the overall quality of the book stand out.

As a ColdFusion developer, however, the book seriously falls short. To be fair, the book isn't intended to be a Coldfusion reference, but there are some serious flaws in the chapter on integration with ColdFusion that could have been avoided if the author and technical editors actually knew ColdFusion. Rather than talk about how to write ColdFusion code, the chapter should have been written with a focus purely on integration with a ColdFusion server. Instead I felt like it tried to fill space by explaining things about ColdFusion that quite frankly were completely incorrect. I'm not as experienced with other web application models like PHP and ASP, but I also felt as if I was rereading documentation, rather than learning something new. I felt as if those chapters were book thickeners, and would have given the book 5 stars had those chapters been more useful.

I was pleased to find a chapter on integrating DWMX 2004 with version control systems - a topic that has been fresh on my mind lately as I consider using Dreamweaver MX 2004 100% of the time.

In short, the book is worth having for any serious web developer. I'm pretty confident that when I run into a problem with DWMX 2004, I'll be able to find an answer in Dreamweaver MX 2004 Demystified.

Posted by Michael Buffington at 11:13 AM in Dreamweaver | Permalink | Comments (0) | TrackBack (0)
This work is licensed under a Creative Commons License.