33 Wood Avenue South Suite 600, Iselin, NJ 08830
4894 Rue de Grand Pre
Montreal, Quebec H2T 2H8
St.John's Innovation Centre
Cowley Road, Cambridge
England CB4 0WS
+44(0)1223 968 433
P.O Box 122766
SAIF Zone, Sharjah, UAE
+971 06 557 9503
+971 55 838 3696
+971 6 557 8549
3-6-327 & 328, First Floor
Doshi Chambers, Basheerbagh
Hyderabad -500 029
Andhra Pradesh, India
+91-40-23261091 / 92
+91-40-23261091 Ext.336

Monthly Archives: May 2014

Exploring Fusebox and Mach II, the most prominent and admired ColdFusion frameworks

Fusebox and Mach II are renowned and standard frameworks for ColdFusion. Compared to Fusebox, Mach II is a relative new comer to the list of ColdFusion frameworks and has quickly become a well-liked framework in the ColdFusion department. They both have certain similarities and differences which are explored in this article.

When users call a Fusebox application, they pass in an “action” value, typically called “fuse actions”. Based on the specified fuse actions, the application executes code to fulfill that request. Owing to the predetermined behavior of single file compile actions by core files results in fast performance because once the “compilation” step happens, all upcoming requests omit that step and carry out the execution of “compiled” fuse actions file directly.

Mach II relies extensively on CFCs. The entire Mach-II framework code is implemented in CFCs.  Users pass an “event” value into a Mach-II application, and the framework acts in response depending upon the particular event requested. This is similar to Fusebox’s “fuse actions”.  Mach-II also requires developers to write CFCs to handle the business logic within an application.

Fusebox and Mach-II are alike in many ways. They both have a set of core files which implement the corresponding frameworks. They both use XML to define how an application responds to requests.

However, there are few differences which are to be taken into account. They are

  1. In a Fusebox application, your XML is split into multiple files, and each file represents a “circuit”. In Mach-II, the XML is all defined in one central file. So your inclination for working with one large central file over smaller individual files may have an effect on your choice.
  2. Mach-II calls for a solid grip of object-oriented programming and contrary is the case with Fusebox. Fusebox framework is procedural and application logic can be written with or without a CFC. Fusebox leaves the choice to leverage CFCs and object-oriented principles up to the developer. The framework does not impose this type of development unlike Mach-II.
  3. Mach-II also enforces the use of the Model-View-Controller (MVC) pattern. This approach tightly detaches the Controller from the Model and the View. Fusebox, in contrast, leaves this decision up to the developer. It is likely to write MVC applications with Fusebox, although it is not mandatory.
  4. Fusebox can “compile” a fuse action into a single file. Such a step is not feasible in Mach-II as a result of its dynamic nature.
  5. Practically all business logic in a Mach-II application is dealt within CFCs. The listeners operate as a communication link connecting the framework and the core business objects. This forces a level of encapsulation on the business objects, because they require some knowledge of the framework. Such encapsulation is achievable in Fusebox; nevertheless it is not imposed by the framework.

Developers who want to build Object Oriented applications with an MVC approach will most likely prefer Mach-II. On the contrary, developers who are accustomed to coding procedural applications will perhaps choose Fusebox. Yet again, Fusebox will support OO-based models with an MVC design; it just doesn’t insist on or require it.


Tags: .