The Fusebox LifeCycle Process has made things much easier for developers of web applications using the Fusebox framework, and there have been several tools developed to help programmers work within these stages.

FuseBuilder is the next logical step from those tools. It gives the Fusebox developer the ability to Wireframe a project, generate static html prototype pages and output fully fusedoc'd application frameworks that can get their display fuses from the approved prototypes. You can even use the recordsets you define in your project to generate the SQL required to create your project's database tables.

FuseBuilder is customizable, extensible and can export projects to frameworks using Fusebox 3 for ColdFusion or PHP, and Fusebox 4 for ColdFusion or Coldfusion MX. The frameworks and prototypes generated come complete with clickable links in the display fuses, or submittable forms.

You can create a fully defined project from scratch, or you can import files from wireframetools (.wir) or Mindmapper / Visual Mind files (.txt). The import process will automatically convert wireframe information into fuseactions, xfas and fuses. Mind map files can contain essentially all the elements for a complete project, which will be imported and converted faithfully to recreate the project in FuseBuilder. You can use the customization form in FuseBuilder to define a directory location for Wireframetools / Mindmapper files for use when creating new projects, allowing for an unprecedented number of input paths.

There are two ways to develop the structure of your project: Wireframe Edit mode and Project View mode.

Using Wireframe Edit mode is a lot like working with other wireframing tools, with the exeption that when you enter a title for the pagestate, you're actually defining circuit/fuseaction names, and when you type in the description of the pagestate you're actually defining the <responsibility> section of that fuse's fusedoc. Additionally, any links that you define are treated as XFAs in that fuseaction. It's a terrific way of quickly defining all the function points for use in scoping out a project for a client, with the added benefit of continued usability after the wireframe is approved. Once the wireframe is frozen you simply go into each fuseaction and continue refining the structure using the Project View mode.

In Project View every element that can be defined in your project is visible and available for adding, editing or deleting. You can create settings or parameters on a circuit level (fbx_Settings) or on a fuseaction level (fbx_Switch or circuit.xml) You can edit the paths of the circuit and see visually how your circuits nest. You can create, rename or delete fuseactions in a circuit, create Remote Fuseactions (<do/> or FuseQ()), define XFAs' names and targets and whether they're accessed via link or form action, and define a cflocation at the end of the fuseaction. You can put a condition around the including of a fuse, which surrounds the <cfinclude> with <cfif> when the framework is generated. You can copy fuseactions or files to other circuits, copy circuits, or import circuits from other projects. With the use of Remote Fuseactions it's possible to define a full project structure using an MVC approach.

At any point in the development of your project's structure you can view the project in Wireframe View. If you're in Wireframe Edit mode, simply click on any of the "circuit.fuseaction" names to enter the pagestate view of that fuseaction. From here you can navigate around the application and simulate the view and access points from one pagestate to the next. You can even define a layout to use with the pagestate view - sort of a pre-prototype. In addition to the pagestate views, there is a summary sheet of all circuit.fuseactions with their possible exits called the Quickmap. You can continue to look at a project in Wireframe mode even after the fuseactions have been developed past the capability of Wireframe Edit mode, such as when you have split the fuseactions into MVC patterns and included them through Remote Fuseactions.

One of the major reasons that more companies don't use Prototypes during the process of developing an application is that the client typically balks at the idea of extra steps that they might have to pay for, and the developer balks at the idea of extra steps that they might not get paid for. With FuseBuilder almost none of the material created while working within FLiP is wasted, because it can be used in the next stage of the process. Prototypes are no exception. Using the template as a basis for layout, FuseBuilder can create static HTML pages representing all the pagestates found in the project's Wireframe. You can define the xfa types -- 'form' or 'link' -- and the layout types for xfas -- 'general', 'breadcrumb', 'menu', etc -- and FuseBuilder will use the corresponding layout blocks in your template design to generate the prototypes in this fashion, with clickable links in the areas of your page that you defined. If you have used the Project View to define all the IO elements, your forms will even be created with corresponding input types and a submit button. You can then use your favorite html editor to complete the layout with any html, javascript, flash etc. When FuseBuilder generates the static HTML prototypes, it also creates a standalone FuseBox application called "fbNotes" within the prototype's web folder for viewing and making notes on each prototype template, and approving the prototypes' content.

Architecting the project takes place in the Project View. Every element that Fusebuilder is capable of generating in the framework is available in this view. You can create, edit and delete Circuits, including defining their path for a directory tree. You can copy circuits from within the project, or copy circuits from another project. You can define settings in the fbx_Settings for each circuit, either as settings (<cfset>) or as parameters (<cfparam>). You can create, edit, delete Fuseactions, or move them up and down in the circuit, or move them into another circuit completely. You can also define the fuseaction as a <pre or <postfuseaction> for use in FB4 applications. In a fuseaction you can also define settings (<cfset> or <cfparam>, though parameters are converted into settings within FB4 frameworks) You can define your XFAs, and identify each XFA as either a link or a form button, and choose the display area of the XFA links, such as "breadcrumb" or "general". You can specify the fuses to be included in the fuseaction, with conditions attached to their inclusion. You can define Remote Fuseactions in a fuseaction, that will be generated either as FuseQ elements in FB3, or as <do/> elements in FB4. The full features of both versions are available for definition, such as storing the Remote Fuseaction in a content variable. You can define a relocate call to take place after the fuseaction is complete (<cflocation> in FB3 and <relocate/> in FB4) The fuse files can be fully fusedoc'd, with the Responsibility, Notes and IN or OUT elements available. Any IN or OUT element defined is available to be imported into other fuses, making it extremely easy to populate the full set of fuses in a fuseaction. Additionally, any IO OUT elements that are scoped as "form" or "url" will automatically be rescoped to "attributes" when imported into the IO IN of another fuse.

FuseBuilder was developed with an eye towards making the fullest use possible of the wireframe and any defined fusedocs during the architecture of the project structure, with the goal being the least amount of "hand coding" possible in the generated framework. To that end, FuseBuilder has several advanced features that enable the developer to rapidly expand on a project that's had its Wireframe approved and use the Wireframe and any of the IO Elements in the fuses' Fusedocs in the architecture of the finished framework.

• Wireframe Layouts and Link Locations: You can create any standard html layout, complete with flash, dhtml or images and assign it as the Wireframe Layout. As soon as you've assigned a layout for use in a project's Wireframe, that layout will be used as the container whenever a fuseaction is clicked into in Wireframe. Enabling "Link Locations" in the project's properties and using a specially formated mix of "block markers" (<fb_general_linkitem>) and "replacement markers" (@xfatext@) in the code of the layout file, you can define blocks of html to be replaced in FuseBuilder with any XFAs, to populate links in areas such as sidebars, breadcrumbs, or menus.
• FuseForms: FuseForms uses any outgoing IO Elements in the display fuses' Fusedocs that are set to a scope of "form" and lets you define all the display properties for each element, such as the label for the form input, and the input type (hidden, checkbox, select box, etc). It then replaces the block of html defined in the Wireframe Layout for that Link Location with each form input and a submit button, providing a form interface that is generated directly into the Wireframe view of a fuseaction. This enables the user to follow the flow of the application by clicking on links and submitting forms, just as they would in the generated framework. This also enables the developer to almost instantly make changes to the interface through client requests, by simply editing the FuseForms definitions for that fuse's Fusedocs.
• FuseQueries: FuseQueries is another way that the Fusedocs in a fuse can be used to reduce the amount of hand-coding after the framework is generated. This feature is available once a Database Definition has been created for a FuseBuilder Project, and allows you to to take any recordset in a Fusedoc and connect each child Element to a corresponding Column in a DB Table, creating a populated query in the "qry_" fuse of your app's generated framework. You can define a query as a "select", "insert", "update" or "delete" query, and can even do the same connecting to incoming IO Elements for use in WHERE clauses etc. All these definitions can be previewed as code within the FuseBuilder interface, in the programming language of your choosing, and can be changed simply by changing the Element's properties in the FuseQueries form.

After your project is fully architected, you can export the project to framework. FuseBuilder comes with four "generators": FB3 for CF, FB3 for PHP, FB4 for CF5 and FB4 for CFMX. A framework generated from a FuseBuilder project will have all the necessary core files, and the switch file for each circuit will be populated with all the defined fuseactions. If you have enabled the Link Locations in your project settings, and set up FuseQueries and FuseForms for any fuses displaying form interfaces, about the only thing that will be left to hand-code is any programming logic in the display fuse, and any "act_" fuses. Because of this, you can generate a working and almost fully functional framework from a FuseBuilder project and have the project finished in record time. All of this in your web browser, using tools that you're already using to complete your Fusebox apps anyways, and at a licensing cost that will pay for itself within the first one or two client projects!