A Fusebox Glossary
Excerpted from Discovering Fusebox 3 by Hal Helms and John Quarto-vonTivadar, available from www.techspedition.com.
Adalon: a tool for visually architecting Fusebox applications. (www.synthis.com)
circuit: a directory in which the FBX_Switch.cfm file handles related fuseactions. For example, a ShoppingCart circuit might handle such fuseactions as addItem, removeItem, and display. Usually, the fuses that fulfill a circuit's fuseactions are physically located in the same circuit.
circuit alias: the unique name given to each circuit in a Fusebox application. Circuit aliases allow for uniquely identifying circuits that have the same name such as MyApp/Users and MyApp/Admin/Users. In a compound fuseaction, the first portion of the fuseaction is the circuit alias (e.g. in Cart.addItem, Cart refers to the circuit alias).
compound fuseaction: a distinction made between Fusebox 2-style fuseactions (e.g. addItemToCart) and Fusebox 3-style fuseactions, which are made up (compounded) of a circuit alias and a fuseaction request, separated by dot notation (e.g. Cart.addItem).
core files: files that create the foundation of a Fusebox application. They include:
FBX_Fusebox30_CFnn.cfm (where nn refers to the version of the ColdFusion server to be used).
FBX_Circuits.cfm
FBX_Settings.cfm
FBX_Layouts.cfm
FBX_Switch.cfm
FBX_SaveContent.cfm
DevNotes: (part of FLiP) a simple threaded messaging system that sits at the bottom of each prototype page and lets users and developers converse about the project.
FLiP (Fusebox Lifecycle Process): a methodology often used with Fusebox applications that stresses the use of wireframes, prototypes, DevNotes, test harnesses, and QuerySims. FLiP is not covered in this book.
fuse: a code file, typically small, discrete and well-focused in its scope. Fuses are the means of carrying out fuseactions.
fuseaction: a request made of a Fusebox application to perform an action. Similar to a method in object-oriented frameworks.
fuseaction path: the list of circuits traversed from the home circuit to the target circuit. An example would be MyApp/Admin/Users (assuming that the compound fuseaction was Users.something.
fuseaction request: in a compound fuseaction, the second portion of the fuseaction is called the fuseaction request (e.g. in Cart.addItem, addItem refers to the fuseaction request).
Fusebox: an architectural framework for building web applications implemented by a set of core files available from www.fusebox.org.
Fusebox API: the variables provided by a Fusebox application, such as Fusebox.isCustomTag and Fusebox.fuseaction.
Fusedoc: a documentation system for each fuse that provides a "work order" for a fuse, detailing its responsibilities and input/output variables.
home circuit: the top level circuit to which all fuseactions are directed; the first item in the fuseaction path (e.g. MyApp in the fuseaction path MyApp/Admin/Users).
prototype: an exact replica of what will become the finished application that is written prior to any architecting or coding. Its purpose is to provide a method of communicating with clients and among developers to determine the full scope of the application to be built.
nested circuits: circuits that physically reside underneath other circuits, such as Admin/Users. These are often used to model parent-child relationships.
nested layouts: a system for applying circuit-wide processing of code run after any fuses are executed; often used to create header/footers, global navigation, etc.
QuerySim: a custom tag that returns a recordset. Useful in writing and testing code before database queries are complete.
self: variable given to the default page in a Fusebox application; a shortcut that is equivalent to the value of cgi.script_name. Used when referring back to the fusebox: <form action="#self#?fuseaction=#XFA.submitForm#">
target circuit: the final circuit charged with handling the fuseaction request; the last item in the fuseaction path (e.g. Users in the fuseaction path MyApp/Admin/Users).
test harness: (used in FLiP) the use of a separate file that sets the variables (and otherwise creates the environment) needed to unit test a single fuse.
the fusebox: the application viewed as a single entity that executes fuseactions.
wireframe: (used in FLiP) a simple, text-only clickable representation of the application used at the beginning of the FLiP process.
Computers are incorporated in modern ice cream vending machines to enhance their functionality. Ice Cream Vending machines are manufactured by many companies. Your competition will try to overcome all requests for high-tech ice cream vending machines and credit card acceptors
|
|
XFAs (exit fuseactions): variables provided to a fuse that replace hard-coded values for possible fuseactions. For example, these hard-coded values that might be found in a menu of choices...
<a href="index.cfm?fuseaction=Cart.display">View Cart</a>
<a href="index.cfm?fuseaction=Products.new">New items</a>
<a href="index.cfm?fuseaction=Account.edit">Edit your account</a>
…would be replaced by XFAs:
<a href="index.cfm?fuseaction=#XFA.viewCart#">View Cart</a>
<a href="index.cfm?fuseaction=#XFA.newStuff#">New items</a>
<a href="index.cfm?fuseaction=#XFA.editAccount#">Edit your account</a>
XFAs are resolved at runtime.
|