1. Fusebox 5 In Action Adam Wayne Lehman ColdFusion Specialist
Adobe Systems, Inc.

2. ColdFusion Specialist at Adobe
About Me
ColdFusion Specialist at Adobe
Solutions Engineer
Technical Evangelist
Member of the ColdFusion Product Team
10+ years of ColdFusion experience
Previous Lives
US Department of State
Johns Hopkins University

3. Agenda Frameworks overview Introduction to FuseBox 5
LitePost in action

4. As Per Wikipedia …
Framework: Support structure in which another software project can be organized and developed. A framework may include support programs, code libraries, a scripting language, or other software to help develop and glue together the different components of a software project. Frameworks are designed with the intent of facilitating software development, by allowing designers and programmers to spend more time on meeting software requirements rather than dealing with the more tedious low level details of providing a working system.
Methodology: (1) "a body of methods, rules, and postulates employed by a discipline", (2) "a particular procedure or set of procedures", or (3) "the analysis of the principles or procedures of inquiry in a particular field". The common idea here is the collection, the comparative study, and the critique of the individual methods that are used in a given discipline or field of inquiry.

5. Understanding The Need
Much of development is repetitive
Basic “plumbing” of an application is often the same from project to project
Lack of standards leads to unique solutions to the same problem on every project
Reinventing the wheel in a different way every time!
Home-grown or roll-your-own methodologies (or worse … lack of a methodology entirely) make it difficult for new developers to jump in on projects
Maintenance is the key!
If we do our jobs right, our applications will spend the majority of their lifecycle in maintenance mode
How do we make our applications easier to maintain?

6. The Framework Solution
Frameworks should make your life as a developer easier
Frameworks handle the basic “plumbing” of the application so you don't have to create this from scratch with each application
Frameworks provide a common organizational language for application development
Easy for any developer familiar with the framework to get up to speed quickly, even if they didn't create the application
A good framework is (relatively) easy to learn
A good framework helps, doesn't hinder

7. Enter Fusebox ColdFusion’s oldest and most popular framework
Also available for ASP, JSP and PHP
Community developed
Originally created by Steve Nelson and Gabe Roffman
Maintained by TeraTech
Encourages best practices
Model-View-Controller (MVC) design pattern
XML based configuration
Since version 4
Long history of development
Original release in 1997!
Latest release (version 5) June 2006
Open source = Free
Fusebox is a popular web development framework for ColdFusion and other web development languages. Fusebox provides Web application developers with a standardized, structured way of developing their applications using a relatively straightforward and easy to learn set of core files and encouraged conventions.
Fusebox is a way to manage the complexity of building a Web application by breaking it up into small, modular pieces.

8. Fusebox Benefits Modularity Severability / Low Coupling Clarity
Model-View-Controller Design Pattern
Enables better planning and prototyping
Supports rapid application development (RAD) and Extreme Programming (XP) techniques
Application modularity
Code reuse
Minimize coding errors
Enables better (easier) testing
Simplify application maintenance
Supports productive team development
Large developer community
Modularity: break the application into smaller, more tightly-defined pieces ("circuits")
Severability / low coupling: make modules as independent of each other as possible by eliminating fixed references and replacing them with variable references
Modularity and Severability promote code reuse. These principles are also shared with OO programming.
Clarity: document the interface (API) to individual code files through structured comments (Fusedoc)

9. Application Structure
Circuit
Fuseaction
Fuse

10. FuseDocs Documentation / structure comment system
Pseudo programming definition language
Inline XML format
Public DTD Available
Optional
XML formatted documentation/structured comment system stored inline each file.
FuseDocs are written before coding so they act as a Programming Definition Language
A FuseDoc will tell the coder both what the individual file is responsible for, what variables are available at runtime and the variables the coder is responsible for creating.
The Fusedoc forms a sort of "work order" from which that the programmer
works. In the same way that machinists work on parts without knowing what
they will be used in, Fusedocs let developers work on code without knowing
about the application, or even the underlying database.
The implications of this are enormous. Some 25 years ago, Fred Brooks
wrote the classic software text, The Mythical Man-Month, in which he pointed
out that adding people to a project that is late actually increases the amount
of time needed to complete the project. The reason? It takes time for those
new developers have to have enough of an understanding of the application
to allow them to contribute. Add to that the increased communication and
coordination time needed to integrate those extra workers and adding
developers only makes a bad situation worse.

11. Fusebox Lifecycle Process (FLiP)
Fusebox is a framework, FLiP is a methodology
Software development lifecycle process
Wireframing
Design Templates
Prototype with DevNotes
Architecture & FuseDocs
Coding
Test Harnesses
You don’t have to follow FLiP to use Fusebox
FLiP stands for Fusebox Lifecycle Process, and is an established software development lifecycle process for developing Fusebox applications.
FLiP was created to combat the astounding 70% failure rate of custom software applications. One of FLiP's fundamental mantras is that "the client can't tell you what they want you to build until they see it". If they knew exactly what they needed at the beginning, they wouldn't need a software architect. They might think they know what they want, but very often they really don't. If you wait until the application is coded to show the customer something, the inevitable changes required by the customer will be very difficult and costly to implement. With this in mind, FLiP focuses on getting customer sign-off on the application before coding begins.
FLiP consists of several phases:
Wireframing - Wireframes are a very simple skeleton of the application. The wireframe has NO graphics, and is focused only on fleshing out the application flow and business logic that the client is looking for.
Design Templates - At this step, visual mock ups of the interface are created.
Prototype with DevNotes - Using the wireframe as a map of application flow, and using the design templates as the basis of the user interface, a prototype is created. The prototype consists mainly of static HTML; no real program code is written. This makes it very easy to change the prototype. The customer views the prototype and enters comments and questions into DevNotes, a simple discussion forum attached to each page of the prototype. Over time, based on these comments, the prototype is refined until the customer is satisfied that the prototype represents the application that they want built. At this point, the prototype is frozen to minimize further changes. The goal is for the frozen prototype to exactly mirror how the final, coded application will look and function. Some people call the prototype the "front end", since the connotation of a "prototype" implies temporary, when in fact the FLiP prototype goes on to become the front end of the final application.
Architecture & Fusedocs - Once the prototype is complete, the architect breaks the application down into circuits, fuseactions and fuses. A Fusedoc is written for each fuse file to explicitly describe what each fuse does. This phase is commonly referred to as creating the schematic.
Coding - Using the Fusedoc, the coders write each fuse file to the specification laid out in each Fusedoc.
Test Harnesses - A test harness is created for each fuse file. The test harness "wraps around" the fuse file and is used to confirm that the fuse functions properly when provided with the appropriate variables.

12. What’s New in FuseBox 5? Backward Compatibility Multiple Applications
Application Initialization
Custom Lexicons
XML Grammar Updates
Runtime Control

13. Fusebox 5 in Action LitePost Demo Configuration files
PDF and FlashPaper 2 reports with <CFReport /> and the ColdFusion Report Builder tool
Integrated printable documents with <CFDocument />
Demonstrate a ColdFusion MX 7 SMS mobile application
LitePost Demo
Configuration files
Basic page request
Plugins
Lexicons

14. Summary Easy to learn, fast to develop
Several print publications available
Accessible to all levels of developers
Promotes best practices (code reuse, MVC, etc)
A good entry point for learning OO concepts
Third-party tools and support
Analyze, Design, Develop, and more
Time tested
10 years of active development
Largest community of ColdFusion developers
Designed by several ColdFusion community leaders (Hal Helms, Sean Corfield…)
Annual conference

15. Resources Fusebox: Developing ColdFusion Application
Jeff Peters & Nat Popovich
New Riders
Discovering FuseBox 4, 2nd Edition
John Quarto-vonTividar
Techspedition
FuseBox 4 & FLIP: Master-Class Applications
What’s New in FuseBox 4.1
Jeff Peters
Proton Arts

16. Resources Official FuseBox website Wikipedia
Wikipedia
Introduction to the Fusebox Framework
Sean Corfield (primary contributor to FuseBox 5)
Hal Helms (Author and contributor)
Jeff Peters (Author and contributor)