Coldspring Powered Fusebox Applications by Adam Lehman

According to a recent poll on CFFrameworks.com, Coldspring is the most used Coldfusion framework, edging out even Fusebox. How has this happend you ask? Well it plays well with others. MachII, Model-Glue and even Fusebox can use CS. MachII and Model-Glue make this reliance more clear with examples, and Model Glue even comes packaged with adapters for CS in the latest version, but examples in Fusebox have been scarce, which is the motivation for Adams talk. After a very good description of MVC and the advantages to using it, time to go over the main aspects of Coldspring. All about the performance gains of using Coldspring rather than creating all the objects at runtime as well as the organizational gains in doing so. Adam hints that in CF8 this will be much faster and not as much of an issue. The main example for the presentation is the FuseboxCS version of the litePost application.

This is the same application used in Adams earlier talk Introduction to Fusebox 5 , but that was the basic fusebox version. Coldspring handles the xml file containing all objects, services, gateways, value objects and data access objects, which fusebox doesn’t need to know anything about. If you want these generated for you, there are some tools out there- – Illidium PU86 generator, and a Flex Builder tool to create these for you as well. Adam goes over the DAO/Gateway/Service/VO objects, as well as their declarations in Coldspring. If something is declared as a property in Coldspring, it’ll need a getXXX method in that object. Lexicons are a way of extending the XML language available in Fusebox.

We want a way to work with Coldspring easier in our Fusebox files. Easy solution is to add an appinit method that will load the Coldspring factory. The actual declaration of the variable is in the Circuit.xml file itself, rather than in an act page. Instead of explicitly declaring coldspring in the application scope, this method will store it in the application.fusebox scope (if i understand correctly). In the end you never have to explicitly call the application.fusebox.coldspring variable (or wherever it is), instead it’ll be called for you by the custom lexicons.

These Lexicons are key feature that drove me to this talk actually. Act pages in fusebox should NOT be your model. Your model should be lightweight enough to be swapped out with a clear distinction of where the controller ends and the model begins. Act pages blur this line most the time. Adam goes over a lot of fusebox verbs for doing this in your circuit.xml file instead such as set, invoke and a custom cs:get.

This will create the rssService object as named in the coldspring config file and set it to the REQUEST variable. These can be declared in the lexicon directory. There is also a Reactor lexicon that works in a very similar manner that will be available in Fusebox 5.1 (or the next release). Lots less files to manage by not having act pages to handle — now folders will only have dsp and circuit.xml.cfm files.

One of the key features is that the model is framework agnostic too. The sample application used, LitePost, has other versions in other frameworks. Also, if you want the sample lexicons, they’re in the bleeding edge release of Fusebox. There should be a version of litepost available for download sometime in the next month or two with examples in multiple frameworks. He promises it’ll be out in February (we’re holding you to that!). You can download the current version from Google Code: LitePost from the repository. Note: This article is full of notes while listening to the presentation, so forgive any typos or lack of grammar. 🙂