OOP links
Thanks to a pair of Charlies and once again to the Coldfusion Weekly Podcast. Links after the jump.
Thanks to a pair of Charlies and once again to the Coldfusion Weekly Podcast. Links after the jump.
Now that we can easily retrieve and display record sets using the Gateway Object, it's time to work with a specific record. Using a Bean to manage the properties of a single data record we can maintain strict control over a record as it is used throughout one or more applications.
One of the biggest reasons to move towards using OO concepts with Coldfusion is to build modular, extendable code libraries which are very easy to reuse throughout an application or group of applications. As a start, we'll begin by moving queries that generally return multiple records into Gateway objects.
In part three of this primer, we discussed how an object's variables scope exists only within itself and is available to any function it contains. Now we need to cover how and why to make a variable only available to a single function.
An object generally knows only about itself, the data contained in its own variables scope. In order for an object to know about external data, it needs a way to "see" it. Passing data into an object, often only when it is created, is called data injection.
We've covered how to write an Object.cfc, as well as how to create an instance of it. In order to understand how to use objects with Coldfusion, we have to first discuss what is and isn't inside an object.
Think of a Coldfusion Component, first introduced in Coldfusion 6, as a container, an object. Inside this object you can store related data, manage related functions, access data sources, implement business logic and more. While Coldfusion is not an Object Oriented Programming Language, using components, we can implement OO programming concepts and solve recurring problems using design patterns.
Queries have been moved out of the View, but now object instantiation has been moved in. Using Implicit Invocation Listeners, we'll remove object instantiation from the View and reference objects and methods from the Controller (mach-ii.xml).
So far we've covered defining events and piecing together the user interface through the controller (mach-ii.xml). Now we need to move queries and business logic out of the View and into the Model. To get started, we'll move queries that return more than one record into Gateway objects using Coldfusion Components.
I'm hooked on those real estate shows where investors find old houses and fix them up. Once they've gone through the house and made plans, they rip out what they don't want or need, keep what they can reuse and then begin new construction. Using Mach-II, we can flip old Coldfusion code into modern, object-oriented applications.