Introduction:
Fusebox is a framework for building web applications. It is meant to make your applications easier to create and maintain. It helps in structuring the application and break things down into discreet pieces. Fusebox is proved to be a standard and the popular application architecture for ColdFusion.
Features of Fusebox:
1. Structured architecture - Scalability, Maintainability, Modularity.
2. Facilitates team development.
3. Self-documents your application.
4. Allows repeatability.
5. Large community.
6. Proven but evolving.
7. Community-driven.
8. Extensible - Fusebox for PHP, JSP, ASP.
9. Quick to learn.
10. Free.
Description on FuseBox:
Fusebox is the powerful and standard framework to create the dynamic web sites or web based applications such as ColdFusion or PHP. Fusebox is a framework for building Web Applications. A Fusebox application is made up of Circuits. A Circuit corresponds to a directory in your application. Within each circuit are one or more Fuseactions. A Fuseaction is a request handler. And finally, a Fuseaction does its work by executing one or more Fuses. Fuses are individual CFML templates such as display files. Fusebox is the most popular and oldest framework for ColdFusion.
The framework uses XML configuration files to define the application settings as well as declaring what each Circuit does and how Fuseactions within each Circuit execute. There is a core set of XML grammar that is used to create these files.
Fusebox does not force the Model-View-Controller (MVC) pattern or Object-Oriented Programming (OOP) on the developer. However, either or both of these development approaches can be used with Fusebox.
Fusebox applications can be created with any text based development tool or even a basic text editor like Notepad or TextEdit. Fusebox 4 and above use XML, so having XML friendly tools is often useful.
General Fusebox Theory:
- Index.cfm is controller - all interaction goes through the Fusebox via Fuseactions.
- Multiple index.cfms for sections of the site, called circuits.
- Root index.cfm handles global variables, root requests.
- Index.cfm acts via cfcase, including files (fuses) and logic.
- If a circuit blows up, the entire site is not blacked out.
- Electrical fuse box metaphor.
- Circuits are modular, thus reusable.
New Extended Fusebox (Hal-style) standard calls for no home application:
- All circuits standalone with individual cfapplication tags and no global variable dependencies – cfparam all vars.
- All circuit index.cfms are cfincluded, not cflocationed.
Circuit:
A circuit is a cohesive group of related fuseactions. A Fusebox application is made up of one or (more often) multiple circuits.
The circuit’s elements define each circuit in the Fusebox application. The circuits' elements contain one or more circuit elements. Each circuit has an attribute such as alias, path, and parent.
Example for a Circuit:
<circuits>
<circuit alias=”document1” path=”member1” parent=””\>
<circuit alias=”document2” path=”member2” parent=””\>
<circuit alias=”document3” path=”member3” parent=””\>
</circuits>
Fuseaction:
A fuseaction is a request handler, usually for a public method. When a Circuit gets a request to perform some action, it receives the request in the form of a fuseaction. A fuseaction is passed or defined for every request the user makes to the application.
Fuse:
A fuse is an individual, atomic code file. Fuses are the most basic building block of a Fusebox application. When a fuseaction is passed to a circuit, one or more fuse files are called to actually fulfill the request. A fuse is always a private, so fuses are never called directly by a user making a request to a Fusebox application.
File Naming Conventions (Fuses):
- app_globals.cfm – File defines variables, instantiates application
request.mainDSN, request.webroot, request.mypath
§ <cfif not IsDefined(“application.applicationname”)> <cfapplication name=“blah”></cfif>
- dsp_filename.cfm - Display file
§ Only file that contains HTML or any output to browser
- act_filename.cfm - Action file
§ Only file allowed to perform actions on the database – updates, inserts, deletes, selects allowed, but only in conjunction with action
- qry_filename.cfm - Query file
§ Extremely modular file can be called “willy-nilly” throughout application, performs selects on database
Core Files:
The core files are the set of ColdFusion or PHP files that comprise the Fusebox framework.The core files are the files needed to actually implement Fusebox. Core Files are available when the FuseBox framework is downloaded.
First Steps (Pre-Coding):
- Produce a quality specification
- Nothing Fusebox specific here
-
- Use fUseML or another modeling tool to make the design including directory structure
- fUseML is derived from the UML.
- Build design taking index.cfm interaction (Fuseactions) into account.
-
- Create stringent Fusedocs for all fuses
- Fuses should not be dependant on any variables not explicitly stated.
- Make assertions if necessary.
-
Sample Application:
<fusedoc fuse="FBX_Circuits.cfm">
<responsibilities>
I define the Circuits structure used with Fusebox 3.0
</responsibilities>
<io>
<out>
<string name="fusebox.circuits.*" comments="set a variable for each circuit name" />
</out>
</io>
</fusedoc>
<cfset fusebox.circuits=StructNew()>
<cfset fusebox.circuits.home="home">
Creating A Fusebox Application:
- Create the index.cfm files
- Create Fuseactions in index.cfm
- Create Fusedocs for fuses
- Write fuses
- Stand back and marvel
Create the Index.cfm Files:
- Every directory (circuit application) has one index.cfm file.
- Index.cfm controls all the Fuseactions of that circuit application.
- It is the Fusebox.
- All links and form submissions go to the index.cfm.
- It is a single cfswitch statement with multiple cfcase statements.
- Each cfcase is a different Fuseaction.
Example:
index.cfm?fuseaction=document.login
Here, central controller is index.cfm and it receives the fuseaction message of document.login.
Document is the circuit name and login is the fuseaction name.
The Fusebox Code:
<!--index.cfm-->
<cf_formURL2attributes>
<cfinclude template=“app_globals.cfm”>
<cfparam name=“attributes.fuseaction” default=“login”>
<cfswitch expression=“#attributes.fuseaction#”>
<cfcase value=“login”>
<cfif blah>
<cf_do_logic>
</cfif>
<cfinclude template=“dsp_UserLogin.cfm”>
</cfcase>
</cfswitch>
Create the Fuseactions:
- A Fuseaction may cfinclude .htm/.cfm; cfmodule; cflocation; contain limited cfml
- A Fuseaction may NOT display anything to the browser or contain “open” SQL
- Determine what steps are needed to complete each Fuseaction
- Add those steps inside each cfcase statement
The Fusebox Code:
<cfcase value=“MainPage”>
<cfif client.IsLoggedIn>
<cflocation purl=“index.cfm?fuseaction=login”>
<cfelse>
<cfinclude template=“dsp_HomePage.cfm”></cfif>
</cfcase>
<cfcase value=“InsertRecord”>
<cfinclude template=“act_InsertNewEmployee.cfm”>
<cfmodule template=“conf/index.cfm?fuseaction=main&ID=7”>
</cfcase>
Extended Fusebox:
- Version 2 calls for multiple Fuseboxes to be tied together with cflocation or cfmodule.
- Version 3 ties Fuseboxes together with cfincludes ONLY.
- There are no longer “circuit” and “home” apps – all index.cfms function standalone – loosely coupled.
- Any Fusebox can cfinclude any other Fusebox without knowing or caring what variables are used or what the Fusebox’s architecture is.
- When the Fuseboxes are collected, they are called from the highest Fusebox only using “dot-notation” href and form action.
- All hrefs and form actions call the current index.cfm which, when Fuseboxes are cfincluded, means the highest Fusebox in the chain, without having to recode links.
<a href=“index.cfm?fuseaction=catalog.view&ID=3&cat=2”>
<a href=“catalog/index.cfm?fuseaction=view&ID=3&cat=2”>
- But this Fusebox can in turn, be called by a higher Fusebox…
Extended Fusebox Code:
<cfswitch expression=“#listfirst(attribs.fuseaction,“.”)#”>
<cfcase value=“cat”>
<cfset attribs.fuseaction=listRest(attribs.fuseaction,“.”)>
<cfinclude template=“../dir/cat/index.cfm>
</cfcase>
<cfcase value=“members”>
<cfset attribs.fuseaction=listRest(attribs.fuseaction,“.”)>
<cfinclude template=“/apps/index.cfm”>
</cfcase>
<cfcase value=“Info”>
<cfinclude template=“qry_ExCheck.cfm”>
<cfinclude template=“dsp_FormPage.cfm”>
</cfcase>
</cfswitch>
Challenges Presented by Fusebox:
The standard Fusebox challenges apply here: some people adapt more quickly than others, and debugging can sometimes be a challenge. In particular, Fusebox 4 can be a challenge for developers unfamiliar with the xml grammar, and moving smoothly between production and development mode can throw new developers for a loop. These are minor potholes, however – well outweighed by the advantages.
Benefits to using Fusebox:
- Increased productivity
- Increased code reusability
- Easier code maintenance
- More productive team development
- Allows developers at the client sites to work on the same source code with Duo developers.
Fusedoc Documentation Standard:
- A Fusedoc outlines responsibilities, customizations, and expectations of fuses, and is unique to each fuse.
- No fuse can assume the existence of any variable unless it is noted in the Fusedoc for that fuse.
- Once completed, a Fusedoc should provide all the information needed to code the fuse – no interaction with application architects or previous specifications should be needed.
Conclusion:
Fusebox framework is used in ColdFusion or PHP for developing the secure web application. Fusebox uses design and technology to create experiences that empower people to share, connect and interact.
0 comments:
Post a Comment