Advanced Fusebox 5: Extending the Language of Fusebox, by Sean Corfield

Notes from “Sean Corfield’s”: talk on Ajax and Model Glue at Frameworks 2007. XML is used by most the top coldfusion frameworks. All of these offer a language for your controllers. One unique feature of Fusebox 5.0 is that it is not limited to the XML vocabulary set in place there and can be expanded with custom XML. Some fusebox basics: there’s a single fusebox.xml file for declaring circuits (top level heirarchy), many circuit.xml files that declare fuseactions, and fuseactions can have a sequence of verbs to actually do things like do, if or include. These verbs are compiled down to cfml at runtime. This means that instead of looping over all files included, Fusebox 4 and later actually do code generation. The built in verbs are called the Fusebox Lexicon (fusebox5/verbs). These are cfml files that output other cfml. An example, a in XML will compile down to . Verbs are basically custom tags. They will validate attributes, may have children and can communicate in limited ways. These children can continue down to any level. Verbs are written in cfscript and generated with fb_appendLine() . Each tag has a start and end to it. Basically this is an if statement where the start statement is run, then any children, then the end if statement. The end result of all this is that when the verb is executed the first time the entire code is run, but the second time only one line will need to be read. Sounds like deterministic functions in mssql.

CFScript should be deprecated and never again used again. I never use CF Script… except when I’m writting Fusebox verbs.

Instead of writing code that produces results, you’re writing code that writes code when you create lexicons. In development mode these are recompiles every time, while in production mode it is cached. To repeat Peter Bell, code generation saves time. You have the initial investment of time in creating the generator, but it pays off with repetitive tasks. Using this you’re programming with concepts instead of nuts and bolts. If this code is in an act page this will be run on each request, while in fusebox 5 as a lexicon it’ll only run what needs to be run. Here’s a sample bit of how these are inculded and run: [xml] [/xml] This path can be a coldfusion mapping if you’re sharing lexicons. Sean is presenting a very cool orm example using ORM lexicons for reading, listing, creating new objects, populating, deleting and saving. These look a lot like the ModelGlue.GenericXXX actions compiled in almost the same amount of xml code. By changing the namespace parameter from Reactor to Transfer in his example he was able to change the ORM used on the page and keep the same end result. If you have a prefuseaction, or define the xfa, you can forward on to an xfa in a circuit as of fusebox 5.1 [xml][/xml] Also, this can create search engine safe URLs using a link such as index.cfm/circuit/fuseaction. This is safe with moderewrite too, and if you change the self and myself fusebox variables you can get rid of the index.cfm part and your links will be down to just /circuit/fuseaction. In addition to the namespace parameter for a circuit, you can create custom attributes. For instance his cat club 7 example (model glue in fusebox) he uses custom views adding a simple line of code to the circuit.xml mg:viewMappings="view" . He also has a classes/class tag in the fusebox.xml where the controllers are defined. The controllers are straight from the model glue application with a custom cfc passed in automatically that mimics the model glue event argument. This really opens up a new way of doing applications. It’s also the second talk that has used fusebox without using act pages for your model calls, which was one of my biggest gripes with fusebox (or maybe just headaches). It’s fast, it’s flexible, it’s not too hard to write reusable code and worth another look. Also, 5.1 should be available in the next few days, which some sample code here relies on; just watch the Fusebox Trac for updates.