Before the advent of RubyOnRails which influenced the growth of many other frameworks, there was Fusebox.
While frameworks like RubyOnRails gain popularity through its promise of rapid development, Fusebox focus was on ease of maintenance and like other frameworks provide a logical way to structure and layout your codes.
Fusebox early success was strongly tied to the success of Cold Fusion and the early days of web development where the non-existence quickly leads to ‘spaghetti codes’.
Fusebox provided that logical structure. More importantly, within Fusebox, is FLiP; a project management approach to estimating, architecting, coding and testing a Fusebox application.
I use FLiP extensively. It is the basis for the cost estimation of projects that I managed. It takes the guess workout of my project plans and the wireframes aids in confirming the requirements and bring clarity to the client’s work process.
Just recently, we need to port a project that has code going as far back as 10 years ago. The saving grace was our use of Fusebox back then.
True to its mission, Fusebox applications continues to be easily maintained. We can easily navigate our codes from 10 years back.Fusebox diagrams from our documentation continue to easily give us an idea how various screens are tied together.
The Fusebox diagram on the left gave us an idea of what’s going on in the ‘Order Circuit’ .
It clearly shows the user that is allowed to access the ‘circuit’, the screens within the circuit and the key ‘actions’ that is associated with it.
Often, we mapped the circuits to the work process of our client’s organisation.
Moving forward, will we still use Fusebox on our future projects? Unfortunately, Fusebox project has lost its momentum. Today, frameworks like YII (for PHP), Django, Pylons for Python and RubyOnRails dominate the framework scene.