Fancy Bread

When learning how to apply object oriented principles to ColdFusion development, one will assuredly encounter the subject of design patterns. Singleton, Factory, Strategy and Bridge are just some of the patterns that describe solutions to common problems in programming. For this example, I'll demonstrate a variation on the Factory Pattern for transient objects. What is a factory? At it's simplest, a factory encapsulates the creation of objects to provide a consistent api for clients. What is a transient object? A typical OO ColdFusion application will incorporate a combination of Singletons (one instance per application - often instantiated at application startup) and Transients (a per request object that is not maintained in a persistent scope).

Read more...

The more I use JSON, the more enamoured I am with the simplicity of the format. For configuration settings, JSON can easily be decoded into structures used to populate simple configuration beans. While updating a legacy application to a service oriented, framework driven implementation, I found the need to access default settings in different contexts. In the legacy app, these defaults were set in many list templates to both pre-populate a form and filter a query. My first inclination was to use Mach-II properties to store the config settings, but with many different pages all having some default params, that would become unwieldy. In order to provide access to the default values in both a view and a Mach-II listener, I decided to build a "ConfigurationService" that would serve up event-focused simple configuration beans from a JSON configuration file.

Read more...

In a previous post about JSLint AIR, I introduced my concept of an "Application" object that was responsible for registering and initializing individual components. In turn, each of these components was responsible for a specific piece of the application, either a UI element, generating a report, or interfacing with the Adobe AIR API. At the time, I thought that it was a good way to initialize different Ext JS components, encapsulate and organize my code. I've since refined that object slightly as I have learned that I was actually employing the Mediator design pattern. Mediator is described in the GoF book, Design Patterns: Elements of Reusable Object-Oriented Software as a behavioural pattern with this intent, "Define an object that encapsulated how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently." If you're a patterns guru, that description might make complete sense, but I find a diagram and examples much easier to comprehend.

Read more...