For those of you who haven’t seen it yet, this is an interview between Michael Smith at Teratech and Steve Nelson here at Webapper, about Steve’s upcoming presentation at the Frameworks Conference, entitled “CFCs ARE the Framework”.

============================================

Michael Smith: Since you created the original Fusebox methodology, can I assume you’re speaking about Fusebox 5?

Steve Nelson: Nope, not this year. I’m talking about an experimental pure-CFC framework. It’s a concept I’ve been playing with for about a year now, and I love it.

Michael Smith: Let me get this straight, you created a new framework?

Steve Nelson: No, not exactly. The code looks and feels exactly like an MVC-style Fusebox application from a conceptual level, but it doesn’t use Fusebox 5 XML or core files. It uses CFCs. My original idea for Fusebox, 10 years ago, was to come up with standard concepts for architecting an application, not come up with a single soup to nuts product. In a nutshell, I’ve created an entirely new implementation of Fusebox. My implementation still uses the concepts of “circuits”, “fuseactions”, “fuses” etc. It just doesn’t use XML files to define circuits, fuseactions, or fuses. Nor does it have any external core files that need versioning and maintenance.

Michael Smith: That’s sacrilegious! All ColdFusion frameworks are organized with XML files.

Steve Nelson: That’s true. The popular CF frameworks today do utilize XML files to organize the architecture code. Which is fine. But that in no way means that’s the only solution. In my opinion, using XML files to create a new framework programming language has more drawbacks than benefits. The biggest drawback is that the developer needs to learn yet another series of tags and syntax and keywords in order to use a framework. That’s a big hurdle to jump, which is why many developers say “[insert framework name] – one of these days I’m going to learn that!”. Fusebox XML has about 20 tags and over 100 attributes of those tags. Many of these tags are 1 to 1 correlations to existing CFML tags with slightly different attributes. i.e. fuseaction==cffunction include==cfinclude. Which makes me question the benefit of using XML to define a framework’s architecture.

Michael Smith: So how does it work?

Steve Nelson: Basically, this Fusebox implementation uses CFCs to manage themselves. This is easier than you’d think. Basically, I use 3 types of CFCs: Model, View and Controller CFCs. Model CFCs run “action” code (cfinclude “qry/act” files). View CFCs run “display” code (cfinclude “dsp” files). Controller CFCs determine which model and views to run (cfinvoke function in other CFCs). That’s about it. My presentation will go into the details of organizing the CFML so this all works together.

Michael Smith: Seems simple enough, but how is this an implementation of Fusebox?

Steve Nelson: There are three main concepts in Fusebox: Circuits, Fuseactions and Fuses. These concepts translate directly over to CFCs. A “Fuseaction” in a URL like: index.cfm?fuseaction=users.listUsers lets the application know what the user is trying to do. In my CFC implementation of Fusebox, it is letting the application know that the user is trying to access the file: c:inetpubmyapplicationcontrollerusersusers.cfc and to run the cffunction: “listUsers”. That cffunction may cfinvoke other cffunctions in the model and/or view folders in the application. Those cffunctions may cfinclude files.

Michael Smith: So a “Fuseaction” is just a cffunction in a CFC?

Steve Nelson: Yep.

Michael Smith: And a “Circuit” is a CFC itself?

Steve Nelson: Well, kind of. I like to think of a circuit as the entire folder that a CFC is in. Because a circuit contains both fuseactions AND fuses.

Michael Smith: Oh, right. So that means a cfincluded file is a “Fuse”?

Steve Nelson: You got it.

Michael Smith: How about performance, is this method fast?

Steve Nelson: It’s VERY FAST. Since there are no core files, nor do the CFCs extend other CFCS, a page request may only call 2 or 3 cfcs and a couple included cfm files. At this point the performance of the application is up to the architect, not the architecture itself.

Michael Smith: But there has to be some overhead, a couple hundred milliseconds?

Steve Nelson: Pfff no way! Maybe 10 milliseconds because it uses CFCs instead of only CFMs. But I think that’s debatable.

Michael Smith: I think I see where you’re going, but I don’t really grasp how you make this all work.

Steve Nelson: Well that’s a good reason to come to the Frameworks Conference on February 1st, in Bethesda, MD. You’ll be there, won’t you?

Michael Smith: No, I’m busy that day. I’m going to be at a Frameworks Conference in Bethesda, MD on February 1st.

Steve Nelson: Oh, that’s too bad. I’m planning on demonstrating all the details of making this work. Well maybe we’ll meet up next year.

Michael Smith: Wait, did you say February 1st?

Steve Nelson: Yes, Thursday 2/01/07 through Friday 2/02/07.

Michael Smith: And you said it’s in Bethesda, Maryland?

Steve Nelson: Right. Bethesda is about 20-30 minutes north of Washington DC (depending on traffic).

Michael Smith: Oh right! Yes, I’ll be there.

Steve Nelson: Well then I’ll see you there.