The Fusebox Framework

The first part of Fusebox is the "framework". The Fusebox framework consists of a series of files that aid in the creation of a complex web application. These files, known as the "core files" allow you to easily achieve nested layouts, inherited variables and settings, and break your application into more manageable pieces. Additionally, a set of best practices for organizing applications falls under the framework. We are a Coldfusion fusebox developer.

With Fusebox 3.0 & 4.x, a clear separation is made between the framework and the methodology. The methodology associated with Fusebox is called the Fusebox Lifecycle Process or FLiP.

Fusebox is a framework consisting of a set of helper files and organizational principles, and a methodology consisting of a set of best practices for managing web projects. Used by application designers, developers and architects, the system addresses development problems such as unmanageable complexity, wasteful redundancy of effort, time-consuming code maintenance, and slow development speed. Digital Mesh is an offshore cold fusion fusebox developer.

The goal of the Fusebox framework is to create a standard process for architecting web applications. This goal extends beyond a single technology. The core files have been duplicated for multiple web application languages.

Through a very specific process, FLiP helps developers by providing them a series of steps for developing a web application: Everything from when and how to talk with your clients down to architecting and coding the application using the Fusebox framework

The Fusebox Methodology

The second part of Fusebox is the methodology. The Fusebox methodology known as the Fusebox Lifecycle Process (FLiP) introduces an elegant new way of managing the software development process. The goal of FLiP is to reduce the atrocious 70% software failure rate. We are a cold fusion mx 7 fusebox development firm.

Fusebox Lifecycle Process (FLiP)

The Fusebox Lifecycle Process (FLiP) is a process for developing web applications. FLiP grew out of some of the best practices employed by Hal Helms and other members of the Fusebox community in the early days of Fusebox. Although, as the name indicates, FLiP came from the Fusebox community, its use is not intrinsically part of a Fusebox application. In fact, the ideas found in FLiP may be successfully employed in non-Fusebox projects as well.

It is also important to note that FLiP is designed for the technical aspects of the project, starting at a point when you are ready to begin building an application. For many simple web projects, FLiP may be sufficient from the start of the project. For more complex projects, other research techniques may be necessary to understand the business model before starting on the application development with FLiP.

There are two fundamental ideas behind FLiP. The first is to use a process that is, at all times, closely tied to client feedback. The second is to encourage inexpensive changes in the design early in the process, resulting in a reduced need for changes later in the process, when those changes become progressively more expensive. We are a coldfusion mx 7 fusebox development firm.

The steps in FLiP are:

1. Personas and Goals

Who will use this software? Why will they use it? A persona is a precise description of the application's user. Instead of designing feature based software, we design goal based software. This process helps deliver software desired by the end user.

2. Wireframe

Wireframing is a way to quickly model the proposed actions that will be performed by the application. The result of wireframing is a clickable model of the application that doesn't look anything like the finished project, but gives the architect an idea of how the client will help the persona achieve their goals. We are an offshore cold fusion mx 7 fusebox development firm.

3. Prototype / Front-End Development

A FLiP prototype is a clickable model of the finished application with no backend behind it. Prototyping is the largest step in the FLiP cycle, generally taking up to 70% of the project's effort. The result of prototyping is something that looks exactly like the finished application, with functionality limited to the client side. The objective is to discover exactly what the client expects from the application, and how they want it to look. Often a tool such as DevNotes is used to facilitate communication with the client about the prototype.

Prototyping is typically done in plain HTML, though if an alternative front-end technology (such as Flash) is being used the prototype may be done using that technology. The finished prototype will become the application's user interface, so the traditional sense of a prototype being a minor, throw-away version is not the case. All the effort made in this step is used in the final application.

4. Application Architecting

Once the prototype is finished, the application architect constructs the application design or schema, identifying fuseactions and organizing them into circuits. Each fuseaction's behavior is broken down into a set of fuses, and the architect writes a Fusedoc and a test harness for each fuse to be produced. Once the design has been constructed, coding can begin. There are some fantastic tools and techniques to use during this step.

5. FuseCoding

Each coder employed on the project is sent one or more fuses and their corresponding test harnesses. The coder writes each fuse according to its Fusedoc. By using the Fusebox framework, the coder's work does not rely on the rest of the application. Each fuse can be coded and tested on its own, and can be plugged into the rest of the application. This step can be accomplished by one coder or many coders.

6. Unit Testing

As each fuse is coded, it is unit tested against its test harness. This gives the coder a way to ensure the correct behavior is produced by the fuse, without being in constant contact with the architect. It also allows the architect to employ any number of coders, none of whom need to know anything about the project as a whole in order to successfully contribute to it. However, if the development team is tightly-knit or consists of only one person, unit testing creates an elegant quality control system for the basic building blocks of the application, ensuring reliability of the entire project.

7. Application Integration

As the fuses are completed, they are returned to the architect, who integrates them into the final application. Daily builds are employed, gradually transforming the prototype into a working application.

8. Deployment

Deployment is the least exciting phase of a FLiP project. Thanks to the high degree of communication between the client and architect, and the architect and coders, deployment day should hold no surprises for anyone.

The Runtime is called from index.cfm and determines which of the other three it needs to complete its work. After initializing a few variables for this request, it determines whether it needs to call the Loader, whose job is to read all the information pertintent to the Fusebox framework -- information about potential messages ("fuseactions") that could be passed in or called, about where certain files ("fuses") are located and how those fuseactions and fuses are arranged ("circuits"), and about extensions to the core file itself via user-written enhancements ("plugins"). This information is stored in an XML compliant file, fusebox.xml, located in the root of the app. If you've defined any grouping of fuseactions and fuses in the form of circuits then for each circuit there will be a corresponding circuit.xml file as well. More on these XML files in a bit, but think of the Loader as a card catalog at the library -- it treats the Runtime as a library patron by providing a detailed listing of what's available and where to find it.

The Fusebox 4 Lifecycle

Now that the central controller -- the "core" if you will -- has this message called a fuseaction, what does it do with it? This section will describe that request lifecycle. In FB4 the core is actually made up of a set of four interacting components. These are the Runtime, the Loader, the Transformer, and the Parser.

To those familiar with Fusebox 3, where such information was effectively loaded on every request, you'll be happy to learn that the Loader performs its task by writing such information to the application scope, resulting in a free-lunch performance increase. Typically this application-wide memory scope is refreshed once a day or thereabouts, depending on your server settings, so in production enviroments the execution time of the Loader is paid only on the first request after the refresh threshold has been reached.

At this point Fusebox 4 takes a leap forward from earlier versions. In all previous versions, the fuseaction at this point was operated on directly: "do A. OK, done with A. Now do B. Ok, done with B. Now do C. OK, done with C." Effectively, the developer was limited to execution of a single fuseaction, and it was difficult (or at least cumbersome) to share common fuses among multiple fuseactions which could make use of it.

Once the Loader, if needed, has finished its job control passes back to the Runtime which does some more request-specific "prep work". Fusebox has long combined variables from both the FORM and URL scope into a unified ATTRIBUTES scope, which gives it some operational advantages for iterative calls to the fusebox.

Instead, Fusebox 4 first determines what a fuseaction means in toto ("Do A, and then B, and then C") and then it actually excutes A, B, C. You can easily imagine that A, B, and C are all themselves more atomic fuseactions, the implication being that fuseactions should indeed be allowed to call other fuseactions. By splitting processing up into two sequential tracks it means the Runtime can store the knowledge of what the fuseaction is meant to do, so that they next time this fuseaction is passed in, it immediately has a "parsed" understanding of what must be done. Further, since the parsed info is written to a static file, it means that this info will be effectively cached by the scripting language service and web server for tremendous speed increases.

Once the FuseQ is completely transformed (in other words, 'when de Do's be done'), it is just a series of pre-defined verbs, forming the Fusebox 4 "grammar". The Parser takes over at that point, parses all the grammar and depending on which scripting language is to be rendered, outputs a full language-specific version of the application you wrote in XML. This is saved to a file so that the next time this fuseaction is requested, the work transformational and parsing work is already completed. Control then passes back to the RunTime and the parsed file is executed.

Now that you understand this difference from previous versions, let's finish up with the Runtime. By the time it is done prepping for the requested fuseaction, it already knows a tremendous amount of information about how the fuseaction related to the application as a whole. If the application and fuseaction parameters are unchanged since the last time this fuseaction was run, it can immediately execute it and its job is done. If anything has changed or a parsed version of the fuseaction doesn't already exist, then it calls the Transformer. The Transformer understands the XML instructions in the various Circuit.xml files and simply arranges that information about the requested fuseaction -- that's the "do A, then B, and then C" part mentioned earlier -- into a Fuse Queue. Or "FuseQ" for short, which some readers will already recognize from earlier releases.

As you can guess, in a production enviroment, there is often infrequent need for Loading the application variables, nor for Transforming or Parsing the fuses making up a fuseaction. The result is a lot of speed.

It's the job of the Fusebox.xml file to configure how your app will operate. You'll use it to define what circuits the app has, what specific property settings the Runtime will operate under, and define the plugins used by your app.

Configuring Your App

In Fusebox 4, it's important to always keep in mind the new differences mentioned earlier. The core files will figure out everything that is involved when executing a fuseaction long before the fuseaction is actually executed. This can be kept in mind by understanding the Fusebox 4 Lifecycle as a series of Phases:

* preProcess: called once, at the beginning of the request processing

* preFuseaction: called once per fuseaction, prior to the invocation of any fuseaction

* postFuseaction: called once per fuseaction, after the inocation of any fuseaction

* fuseactionException: called once per fuseaction, if any exception was thrown during that fuseaction

* postProcess: called once, at the end of the request processing

* processError: called once, if any error was thrown during the request processing

Circuits

The concept of a circuit is an issue of complexity management. Often there are a number of related fuseactions all of which share common code or which can be group by a similar topology. Circuits allow a small measure of inheritance between related circuits and if not taken to a great extreme can also provide some encapsulation. In Fusebox 4, all fuseactions are associated with a circuit and a "fully qualified fuseaction" is one which specifies both the fuseaction name as well as the circuit it is part of. We saw that earlier with the fully qualified fuseaction of "Marie.eatCake": "Marie" is the circuit, and "eatCake is the fuseaction. You may find it a useful habit to name your circuits what what it is and your fuseactions by what it does. Another way of saying this is to name your circuits after nouns (such as "Marie") and your fuseactions after verbs or predicate phrases (such as "eatCake"). Using a Circuit.xml you can specify which fuseactions are part of the circuit, as well as the access modifier and permissions of those fuseactions. You can also specify such properties of the circuit itself, in which case a fuseaction will inherit those settings just by virtue of belong to a circuit.

Typically you'll just download a free (or fee?) plugin and drop it into your application and forget about it. Most developers won't need to write any plugins of their own but it sure is fun to add custom functionality to your application without touching the core files and therefore remaining "Fusebox 4" compliant!

Extending Core File Functionality

Fusebox 4 also introduces the idea of extending the core functionality of Fusebox through "plugins" -- templates that are registered in Fusebox.xml and are called at each "plugin point". At present, there are six plugin points, corresponding to the six Phases mentioned earlier: Good candidates for plugins include security and validation, logging, and layouts/skins. Note that plugins for a given plugin point "fire" in the order specified in your fusebox.xml file. The preProcess plugins fire before any preProcess global fuseactions, and the preFuseaction plugins fire before any preFuseaction fuseactions. Conversely, the postFuseaction plugins fire after any postFuseaction fuseactions, and the postProcess plugins fire after any postProcess global fuseactions.