Fusebox 4 News

After a year and a half, we now have a new version of Fusebox. Or, to be more accurate, two new versions of Fusebox. The reason for the dual track is that Fusebox 4 and Fusebox MX address different types of developers. Fusebox 4 extends the Fusebox 3 framework, adding some excellent new features and simplifying others. It is a framework built (as was Fusebox 3) for procedural development, and while the beta requires CFMX, when the framework is released, there will be CF5 version as well as a CFMX one. No CFCs were used in building the framework, but extensive use of CFMX's excellent XML-processing was. For the final release, we'll be incorporating an XML parsing engine to replace CFMX's native abilities.

Computers are incorporated in modern ice cream vending machines to enhance their functionality. Ice Cream Vending machines are manufactured by many companies. Your competition will try to overcome all requests for high-tech ice cream vending machines and credit card acceptors

Here are some of Fusebox 4's new or extended features:

• FBX_Switch.cfm is replaced with an XML file, circuit.xml.cfm.
• The new circuit.xml file has its own XML grammar, such as <do>, <set>, <if> <loop>, <xfa>, etc.
• Multiple fuseactions can be executed within the same http request. This is particularly important if you want to implement the Model-View-Controller (MVC) design pattern.
• You can specify "global fuseactions" -- fuseactions that are meant to run before any specific fuseaction is processed.
• Circuits and fuseactions have optional "access modifiers". The possible values are public (available to all), private (available only to other fuseactions in the same circuit), and internal (available to any other fuseaction, but cannot be called from a url).
• Layouts lose their special status, simply becoming another fuseaction. Nested layouts become far more flexbile -- no longer tied to the underlying directory structure.
• Content component variables (CCVs) are introduced. A CCV allows a developer to declare that some or all of the code specified in an xml file should not be displayed, but saved instead to a variable. This is excellent for "skinning" content and is used to great effect in portal-type pages, in which the display page is made up of a number of smaller content pieces.
• Fusebox 4 employs a parsing system, in which the meaning of a fuseaction is broken down into a set of simple statements. These statements are saved as a file with the format circuit.fuseaction.cfm. At runtime, the core file can simply include this file. The performance ramifications of this are very considerable: FB4 should run much faster than FB3.
• Plugins provide a way of extending the functionality of the core Fusebox framework without rewriting the core files. Plugins will prove particularly useful in such areas as security and exception handling.

There's a wealth of new stuff in Fusebox 4, and great pains were made to keep it simple while we made it as powerful as we could. Kudos for Fusebox 4 go to John Quarto-vonTivadar, who was the guiding force behind FB4. Fusebox 4 is now in beta. You can download both the core files and some sample applications from beta.fusebox.org. The release date is planned for early July.

Fusebox MX is something completely different. Fusebox MX is written entirely in CFCs and departs from Fusebox 3 and 4's "pipe-and-filter" architecture to a more flexible event-based, implicit invocation architecture. I jokingly remarked to the Atlanta CFUG that we chose this architecture because of its cool name. In fact, we chose it because it provides maximal flexibility to adapt to change. One aspect of frameworks in general is that, while they're good at helping developers write code initially, they're less successful at insulating the developer from the hassles of maintaining applications.

Fusebox MX can help in maintaining code. To understand why, you need to understand a bit about event-based, implicit invocation architectures. One of the main roles of the application architect is defining the mappings between fuseactions, events, and listeners. This is all done in a Fusebox.xml file.

I'll get to the technical terms in a moment, but first, let me tell you a little story that I hope will be illustrative. For this, I need to temporarily transport you back an indeterminate number of centuries to the Court of King Zardof the Magnificent (also known as Zardof the Cheapskate). As you'll remember from your Fictional History 202 class, Zardof had a daughter, Baddabingh, who was renowned for both her beauty and her brains. Would-be suitors sought to win her favor by composing particularly elegant sorting algorithms. Unfortunately, Baddabingh was quick to pick holes in the algorithm, and each failed suitor would, in turn, retire in disgrace.

One day, a new suitor appeared on the scene while Baddabingh was with her maid-in-waiting-and-waiting. (Apparently some of these sorts took a long time to run...) The new suitor showed her a new sorting algorithm called a "heapsort". The Princess was so overcome with its simplicity, elegance and beauty (although some cynics said that even then, she saw the enormous commerical possibilities of it) that she agreed to marry the young algorithm-maker on the spot. Her maid promptly ran off to tell the King.

Since the King was unskilled in such matters and unsure exactly what steps to take, he decided that the proper course of action was to simply announce to the kingdom the good news of his daughter's engagement. It was well known that Baddabingh was being courted, of course, and many merchants were eagerly awaiting the news of her engagement. Once it was known that Baddabingh had decided to marry, a virtual army of shopkeepers, craftsmen, and purveyors of all sorts went into action. As they were given details on the event, each responded with a list of goods and services that they could provide to the court.

To protect the court's time, the merchants were asked to provide their bids in sealed envelopes. One of the court officials was appointed to be "Controller". Once all bids were in, this official tallied the costs. Zardof the Cheapskate had set limits on the amount he was willing to spend on his daughter's wedding (hence his nickname). If the costs were at or below this limit, the Controller would have heralds announcing the upcoming event of Baddabingh's marriage. If the costs were too high, the King would announce that soothsayers had determined that the upcoming marriage was "inpropitious at the current moment" -- a signal to the suppliers to lower their prices.

What has all this to do with event-based, implicit invocation architectures? I was afraid someone might ask this question, and so I've prepared an explanation. If we were to translate certain aspects of this heart-warming story to the new Fusebox MX architecture, you might say that the maid who told the King of Baddabingh's acceptance of her suitor (whose name, unfortunately, has been lost to history) represented a fuseaction. The King, unsure of exactly what to do, created an Event called EngagementOfPrincess. Various interested parties were listening for just such an event. They went into action, returning their proposals into a resultKey. Based on her own computations, the controller decided what to announce a new Event, either MarriageOfPrincess or UnfavorableOmen.

In Fusebox MX, a fuseaction maps to a particular Event type. An Event is a CFC that extends the abstract CFC, Event. Form and URL variables are captured in this Event. Various circuits register themselves as listeners for particular event types. When such an event occurs, the framework notifies each circuit, passing a reference to the Event object itself. Each circuit is provided with a resultKey -- a variable in which to pass any information back to the Event. (Sometimes, of course, there is no information to pass back.) Each circuit decides on how they wish to be notified, by associating an extension of CircuitInvoker. In the code available at beta.fusebox.org, all circuits use a CFCInvoker -- indicating that each circuit is a CFC.

However, the purpose of having a general, abstract CFC, CircuitInvoker, is to allow for subclassing and in fact, CFCInvoker, is nothing more than a subclass provided for use with CFC-type circuits. One can readily see that other subtypes such as WebServicesInvoker, EJBInvoker, and DotNetInvoker would allow Fusebox MX to operate in a technologically heterogenous environment -- big plusses for maintainability and flexibility.

It's important to note that the Event is ignorant of what actions listeners may take. It's not that the Event provides instructions on what to do; it simply "is" and notification of this (along with a reference to the Event) is sent to each listener. Finally, the Event can determine what to do next within its selectView() method. This can be a simple inclusion of a page or it can be an invocation of another CFC or the creation of a new Event (thus beginning a new round of listeners and controller).

Kudos for Fusebox MX go to Ben Edwards, who was the guiding force behind FBMX's event-based, implicit invocation architecture. In discussing this with the Atlanta CFUG, I said, "Fusebox MX represents a software engineering approach to designing web-based software." If the ideas behind Fusebox MX intrigue you, check out the alpha code available at beta.fusebox.org. A couple of very simple applications are available and we'll be releasing more substantial ones soon. Just remember that this is alpha code and is very likely to change (although the underlying concepts are solid).

Is it time for you to learn object orientation? If so, we can help. Ben Edwards and I are teaching our "Java for ColdFusion Programmers" class June 23-27 in Arlington, VA. But the class is filling quickly. If you're interested, you can read more and sign up at www.halhelms.com.

To unsubscribe/change profile: click here

To subscribe: click here