September 18th - September 19th, 2004
Rockville, MD

NEWS

 

Until the Fusebox conference ( September 18th - September 19th), we will be talking with featured speakers at the conference.

Interviews

2. John Quarto-vonTivadar - New Aspects of Fusebox 4.1

In this Fusebox Conference interview, Michael Smith talks with John Quarto-vonTivadar about Fusebox 4.1 invoke, assert and more.

Michael Smith: I'm talking with John Quarto-vonTivadar about his talk on "New Aspects of Fusebox 4.1". John, is 4.1 released now?

John Quarto-vonTivadar: We're releasing it at the conference, so there's another reason to attend.

MS: What's slated for 4.1?

JQ: There are a couple of big features and then some smaller ones. The big ones include a way of invoking objects - either CFCs or Java objects - declaratively, and a new "assert" tag that will add assertions to Fusebox.

MS: Let's talk about invoking objects first. What does it mean to invoke them "declaratively".

JQ: The circuit.xml file provides a way to specify what actions should be taken for a given fuseaction. Because this specification is done in XML and not code, Fusebox is a declarative framework. Prior to 4.1, you couldn't declare a method call on an object from this XML file. With 4.1, you declare an object invocation just as easily as you declare an "include" or a "do".

MS: But you can presently include a file that invokes an object.

JQ: Yes, but this added a layer to the Fusebox application that obscured the intention of the architect. One of the great things about the circuit.xml files is that they make the flow of the application obvious. With the addition of the "invoke" tag, this obscurity goes away and the application's structure becomes more transparent.

MS: Why is that a good thing?

JQ: Chiefly for maintenance of the application. We know that 70-90% of an application's cost throughout its entire lifecycle will be spent in maintenance, so having the structure of the application obvious to developers really helps in reducing bugs and cutting down the time needed to do application maintenance.

MS: And you can do this with both Java objects and CFCs?

JQ: Right. One of the things we're seeing is that developers are using objects in conjunction with Fusebox. Now, there are different ways to do this. You might have a full blown object model sitting as a separate tier - an object domain model - or you might just use objects simply as very nice encapsulation modules.

MS: Fusebox lets you do either?

JQ: Exactly. We recognize that not everyone is going to jump head first into OO, so Fusebox lets you use objects in the way that best fits your development style.

MS: That's great. Now, what about this "assert" tag? What does that do?

JQ: Assertions are a great way of stating: "I expect this condition to be true at run time. If not, I want some specific action(s) taken."

MS: Can you give an example?

JQ: Sure. Let's say that you have a shopping cart. When the person adjusts the quantity of a cart, you expect that the quantity will be an integer that is greater than 0 and, say, less than 100. You can write this into the code itself, of course, but the assertion tag allows you to specify it right in the circuit.xml file.

MS: Declaratively.

JQ: Exactly. And again, having this makes the handling of a fuseaction more obvious.

MS: What happens if a condition that's expected to be true isn't?

JQ: The developer can specify a new fuseaction to be called in that situation.

MS: Is this something that other languages have built in?

JQ: Some of them do - Java, for instance.

MS: OK, and what about the smaller innovations to Fusebox 4.1?

JQ: We've listened to the requests of developers and tried to incorporate them into Fusebox without adding unnecessarily to the complexity of the framework.

MS: And complexity is a Bad Thing(tm)?

JQ: It's one of the biggest problems with any technology: it starts out fairly simply and over time, it gets tinkered with. New features keep getting piled on until learning and incorporating these new features becomes an impediment to actually using the technology. One of my favorite quotes comes from Albert Einstein: "Any intelligent fool can make something bigger and more complex. It takes a touch of genius - and a lot of courage - to move in the opposite direction." Fusebox has always been about making life EASIER for developers and application development FASTER. So, we've resisted the temptation to load up Fusebox with tons of "stuff".

MS: So what new features have you added?

JQ: One small, but useful, feature is adding the ability to save the results of an "include" tag into a variable for later use. Another is that we're removing the need to have each app have its own Fusebox core files. If you wish, you can have a single Fusebox directory containing the core files that all apps use.

MS: That sounds good, but do you have to change your existing apps?

JQ: Not if you don't want to, no. We're very conscious of the need to have existing FB 4 apps run without any change to them. As Fusebox was maturing, one of the things none of us liked about it was that each new version required big changes. Now that Fusebox has matured - and especially with the use of the circuit.xml files - changes to the framework will be done in such a way that existing apps continue to run.

MS: That's a welcome relief.

JQ: Yes.

MS: Any others?

JQ: We've got a few more we're working on, but I'll just save those for my talk.

Michael. OK. Thanks, John. It sounds like Fusebox 4.1 is going to be a very nice point release.

JQ: Our goal is that with each version of Fusebox, we make life easier for developers while giving them greater empowerment. We want to make heroes out of Fuseboxers.

MS: We'll look forward to your presentation.

 

Previous Interviews:
Week 1: Hal Helms - Keynote Speech

|  HOME  |  DIRECTIONS  |  HOTEL  |  SCHEDULE  |
|  TOPICS  |  SPEAKERS  |  REGISTER  |  CF CONF CENTRAL  |