Welcome!

You will be redirected in 30 seconds or close now.

ColdFusion Authors: Yakov Fain, Jeremy Geelan, Maureen O'Gara, Nancy Y. Nee, Tad Anderson

Related Topics: ColdFusion

ColdFusion: Article

Fusebox 4

Fusebox 4

The latest version of Fusebox - version 4 - has been taken out of beta and placed into general availability. Over the last seven years, Fusebox has grown from a collection of best practices and snippets of code into a full-featured, robust framework on which developers can build true Web applications.

Over these seven years, Fusebox has become the overwhelming favorite of ColdFusion developers, and it has been ported to JSP, PHP, and Lasso. Organizations as large as UPS, Casio, Dell Computers, the U.S. Air Force, the U.S. Army, and Rooms to Go employ Fusebox on their Web sites, intranets, and extranets.

Fusebox is built around the idea of a central controller (the Fusebox) that handles requests (fuseactions) and delegates them to smaller, focused controllers (circuits). These components, in turn, delegate work to individual code files (fuses). Fusebox comes with a set of core files (downloadable from fusebox.org) that implement the framework.

Language-Independent XML
This latest version of Fusebox was almost a year in the making, and comes with added features, bug fixes, and improved performance. The most obvious change is in the controller elements. Previously, an fbx_switch.cfm file found in each circuit contained ColdFusion code to determine which actions were to be taken for each request. For example, this code might be used for a login circuit that was meant to respond to the fuseactions, login, and validateLogin (see Listing 1).

In Fusebox 4, the fbx_switch file is replaced with a circuit.xml file. This file has no ColdFusion code; the file consists of nothing but XML (see Listing 2).

Why the move to XML? XML offers Fusebox architects the ability to state their intention without resorting to code. But what's wrong with code? Nothing, of course, but a code-independent XML grammar allows the underlying Fusebox core code to change without affecting the code written for an application. It provides an interface between the architect's intention and the code's implementation.

This means that the core code for, say, a future Fusebox 5 could be substantially different from Fusebox 4, but not break any Fusebox 4 application code. The issue of backwards compatibility must concern providers of any technology. The use of a stable interface that is later translated into implementing code is one of the best ways of dealing with this problem.

XML Grammar
The purpose of the circuit.xml file, where this grammar will be used, is to define the meaning - not the implementation - of a fuseaction. For that reason, the XML grammar set used in these files is quite small; implementation details should be handled by fuses. Even with a constrained grammar set urging them against it, Fusebox architects must be careful to avoid writing implementation code in circuit files. Table 1 lays out the XML elements that can be used in the circuit.xml file.

 

As with all XML, the circuit.xml file must be well-formed - that is, it must conform to the rules for proper XML usage, such as the use of a closing slash in elements that have no closing tag.

While the XML file initially looks very different from Fusebox 3's fbx_switch file, experience among the beta group has shown that adapting to the new format is fast and easy for existing Fuseboxers.

Performance Through Parsing
One of the largest changes to Fusebox is largely invisible to Fusebox programmers. In previous versions of Fusebox, the core files were read on each request and all processing was handled dynamically - that is, at runtime. This created an overhead common to all dynamic processing models.

Fusebox 4 handles things very differently. Much of what had been dynamically determined is now handled in a separate parsing cycle that executes prior to runtime. The Fusebox 4 XML files are parsed and a single file is produced for each fuseaction, using the syntax: parsed.circuitname.fuseactionname.cfm. All such files are automatically placed in a parsed directory.

At runtime, index.cfm (or whatever the default file is) calls the Fusebox 4 runtime file, fusebox40.runtime file. The first job of the runtime file is to ensure that the parsing cycle has been run - and that no changes to XML files have been introduced since the time last parsed. If the runtime file code determines that the parsed files are not up to date (or are missing altogether), it calls fusebox40.loader, fusebox40.parser, and fusebox40.transformer, all of which work together to produce the parsed files located in the parsed directory.

By preparsing the code, the runtime logic needs only to include the appropriate parsed file. That is, if a request is made of the application to execute the fuseaction, home.main, for example, the runtime code (once it has assured itself that the existing state of parsed files is current) includes the file, parsed/parsed.home.main.cfm. By resolving as many dynamic issues as possible before runtime, performance is greatly improved.

Extending Fusebox with Plug-ins
Fusebox 4 also introduces the idea of plug-ins. Plug-ins provide developers a way of extending Fusebox's core functionality without having to tinker with the core Fusebox code. If the Fusebox core file is written to accommodate virtually any developer working on any project, and the application code is written to deal with individual fuseaction requests, plug-ins inhabit the middle ground - code that should run across multiple fuseactions within an application.

What can plug-ins do? Virtually anything - from logging requests to implementing security to... well, anything. Plug-ins allow the programmer to add application-wide functionality that the Fusebox core designers did not or could not anticipate.

Once the plug-in code is written, it is placed in the plug-ins directory. The plug-in designer determines at which of six plug-in points he or she wishes the plug-in code to run. This decision is registered in another XML file, fusebox.xml, located in the root directory.

The plug-in points reflect different stages of a fuseaction life cycle, such as preprocess (before anything else happens), prefuseaction (immediately prior to a fuseaction call), postfuseaction, and postprocess. The other two plug-in points are not temporally based, but occur when exceptions occur.

Plug-ins provide great extensibility to Fusebox without compromising the integrity of the Fusebox core files. During the beta cycle, several members wrote plug-ins to deal with common issues (such as security) and we expect to see plug-ins used as commonly as custom tags.

Exceptions, Layouts, Accessibility, and Content Components
As good as Fusebox 3 was, it suffered from one unfortunate liability: its exception handling was poor, and Fuseboxers have suffered with obscure exception messages since its release. Built into Fusebox 4 is the ability for the programmer to specify a module to call when an exception is thrown. The particulars of handling exceptions can then be handled by a plug-in. This provides enormous flexibility for a wide variety of needs.

Layouts in Fusebox 3 were exceptionally helpful. In Fusebox 4, they just get better. While Fusebox 3 tied layouts to the physical directory structure, this restriction is gone in Fusebox 4. Layout files lose their special status and simply become a fuseaction, making them easier to build and to employ.

While Fusebox 3 existed uneasily with ColdFusion's tag, this is no longer the case; developers needing to use can do so with impunity. The changes made to layouts also make Fusebox 4 more accessible to users with visual impairments by supporting Section 508 accessibility standards. Especially for government agencies - often charged with "508" issues - this represents a breakthrough.

Fusebox 4 also introduces the idea of granularizing content by providing content component variables that can be combined to form a larger Web page. Content component variables (CCVs) allow fuseactions to concentrate on building pieces of content while deferring the placement and usage of these components to another fuseaction. One obvious use for this technology is the building of portal-style pages, but it can be used whenever developers want to make display code more reusable. CCVs allow for far greater reusability of these components than was available previously.

Is Fusebox 4 for You?
So, with all this "new stuff," how disruptive is the move from Fusebox 3 to Fusebox 4? Surprisingly, not very. In a typical Fusebox application, well over 90% of code written is in fuses. None of this code changes at all. Members of the Fusebox 4 beta group were pleased by how simple porting Fusebox 3 applications to Fusebox 4 was. One member related that an application that had taken over a month to build was upgraded to Fusebox 4 in less than two hours.

Is Fusebox 4 for everyone? Certainly not. Some developers have created their own frameworks that work well for them and their team. Some chafe at the idea of working within any framework. Still others want to use a true object-oriented framework, while Fusebox 4 is solidly procedural. (For more information on an object-oriented framework see the article in the August issue of CFDJ, "Mach-II: Breaking the Procedural Barrier, Vol. 5, issue 8.")

Is Fusebox for you? Of course, you're the only one who can make that judgment, but if you're looking for a powerful, robust, mature framework on which to build solid ColdFusion applications, Fusebox 4 definitely deserves your attention. For more information, including sample applications and core code, visit fusebox.org. If you're interested in attending the Fusebox conference in Las Vegas, visit www.cfconf.org/fusebox2003.

Note: Thanks to John Quarto, Brian Kotek, Sandy Clark, Perry Woodin, and Brian LeRoux for making available to me a pre-release copy of their upcoming book, Discovering Fusebox 4, available at techspedition.com.

More Stories By Hal Helms

Hal Helms is a well-known speaker/writer/strategist on software development issues. He holds training sessions on Java, ColdFusion, and software development processes. He authors a popular monthly newsletter series. For more information, contact him at hal (at) halhelms.com or see his website, www.halhelms.com.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


IoT & Smart Cities Stories
Dion Hinchcliffe is an internationally recognized digital expert, bestselling book author, frequent keynote speaker, analyst, futurist, and transformation expert based in Washington, DC. He is currently Chief Strategy Officer at the industry-leading digital strategy and online community solutions firm, 7Summits.
Digital Transformation is much more than a buzzword. The radical shift to digital mechanisms for almost every process is evident across all industries and verticals. This is often especially true in financial services, where the legacy environment is many times unable to keep up with the rapidly shifting demands of the consumer. The constant pressure to provide complete, omnichannel delivery of customer-facing solutions to meet both regulatory and customer demands is putting enormous pressure on...
IoT is rapidly becoming mainstream as more and more investments are made into the platforms and technology. As this movement continues to expand and gain momentum it creates a massive wall of noise that can be difficult to sift through. Unfortunately, this inevitably makes IoT less approachable for people to get started with and can hamper efforts to integrate this key technology into your own portfolio. There are so many connected products already in place today with many hundreds more on the h...
The standardization of container runtimes and images has sparked the creation of an almost overwhelming number of new open source projects that build on and otherwise work with these specifications. Of course, there's Kubernetes, which orchestrates and manages collections of containers. It was one of the first and best-known examples of projects that make containers truly useful for production use. However, more recently, the container ecosystem has truly exploded. A service mesh like Istio addr...
Digital Transformation: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As automation and artificial intelligence (AI) power solution development and delivery, many businesses need to build backend cloud capabilities. Well-poised organizations, marketing smart devices with AI and BlockChain capabilities prepare to refine compliance and regulatory capabilities in 2018. Volumes of health, financial, technical and privacy data, along with tightening compliance requirements by...
Charles Araujo is an industry analyst, internationally recognized authority on the Digital Enterprise and author of The Quantum Age of IT: Why Everything You Know About IT is About to Change. As Principal Analyst with Intellyx, he writes, speaks and advises organizations on how to navigate through this time of disruption. He is also the founder of The Institute for Digital Transformation and a sought after keynote speaker. He has been a regular contributor to both InformationWeek and CIO Insight...
Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
To Really Work for Enterprises, MultiCloud Adoption Requires Far Better and Inclusive Cloud Monitoring and Cost Management … But How? Overwhelmingly, even as enterprises have adopted cloud computing and are expanding to multi-cloud computing, IT leaders remain concerned about how to monitor, manage and control costs across hybrid and multi-cloud deployments. It’s clear that traditional IT monitoring and management approaches, designed after all for on-premises data centers, are falling short in ...
In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...