To frame or not to frame
There are a lot of catch phrases out there when dealing with ColdFusion programming, or any custom programming for that matter. One of these is ‘frameworks’. So what is a framework? Well, it’s just what it says, a framework. Perhaps a better word would be skeleton. The purpose of a framework is to have a program control flow pre-built in to a project, so in theory, it can be created with greater efficiency, from design to development to maintenance. Over the years here at DDA, I’ve created a custom framework that I tend to use in all of our projects. In comparison to frameworks such as Fusebox, Coldspring, ColdBox, Mach II, Model-Glue, (the list goes on) for ColdFusion programming, it may be small and custom, but it is comfortable. In the world of getting projects done on time and on budget, it’s difficult to take on the task of first learning to use a pre-built framework, so the one I’ve created has evolved over time.
Now when I say that I’ve created a custom ColdFusion framework, I use the term loosely. It contains wrappers and reusable elements, some touches of standard architecture, but it’s not very structured, like some of the more sophisticated frameworks are. Since it has been an evolution, it tends to change with each new project, because each project is a custom program on its own, but the bones usually remain the same. What I have tried to do is separate out some of the functionality from design and both containing great reusable parts by using CFCs to wrap up commonly used functions. Someday maybe I’ll have a chance to work with a traditional ColdFusion framework – take the time and energy to go through the plethora of choices and pick one I like, and use it. Maybe it’ll make my life easier. Until then, my custom programmed framework will just have to do.