The State of Object Oriented Programming in ColdFusion
posted under category: ColdFusion on March 13, 2006 by Nathan
We are nearing the end of the basic adapting phase
CFMX is 4 years old. Most developers have upgraded, at least to 6.0. It should be noted that CFMX 6.1 (a free upgrade from 6.0) should be the required minimum for true OOP in CF. Most developers working on 6.0+ have created or used at least one CFC (ColdFusion Component, CF's basic object type), for one reason or another.We are deep into the learning phase
More developers are wrapping their heads around Objects. We're all starting to wake up to this programming model, but it's still new to us. We lack a truly definitive "do it this way" OOP discussions have, largely, turned from "who cares" or "why oo" into "How". The "Why" questions are now learning opportunities, such as "Why should I do it your way," and "why do you do it that way."We can't get out of this phase until we have enough training material out there, and until the community, at large, reads it and begins to really think in objects. There's a chance we'll never get out of this phase. Thinking back to my first CF training class, there may be no way to truly graduate this phase, although Java has done a remarkable job - new developers expect the learning curve, while most new CF developers don't know exactly what they're getting into.
Lots more after the jump...
We are in the beginnings of the maturing phase
Maturity is our goal (ok, it should be). I have a hard time defining OOP's maturity in the CF field, but I think there are a few signs of it coming.The CF.Objective() conference is one clear indicator. This is a new conference this year for CF OOP developers. This is a sure sign that things are changing and OOP in ColdFusion is becoming much more "real."
Frameworks, as another point, are increasingly object oriented. Even the traditional Fusebox framework now has full support for an OOP lifestyle, and the Fusebox 5 framework is being rebuild using CFCs (though the procedural circuit/fuse paradigm will likely not change). Mach II was an early OO framework for CF, introducing events, and (mostly) forcing OOP style code to implement it. Model-Glue is a newer framework that promises to bend OOP into a format traditional CF developer will understand and adopt. Then we have supporters, such as Coldspring, a high quality object factory and Reactor, ARF! and Transfer, ORMs to manage your data interaction. There are far too many others for me to mention. The framework camp, while seemingly crowded, is greatly helping to shape the way we write our programs.
It should be noted that these frameworks are all open source and community supported. This is another sign of the CF community at large growing and maturing.
Where are we going?
Prediction #1. In the near future we will see a lot more frameworks being tied together. There has been talk about "auto wiring" of frameworks. I see a lot of promise in this area. Model-Glue 2.0 is called "Unity," one guess as to why.Prediction #2. You, as an average joe developer, are going to use a framework. There's no way around it. You will be assimilated, if you haven't been already. I'm not saying you'll convert to Fusebox or Model-Glue, but take a look at Coldspring or Reactor, or many of the others not in the mainline scope of frameworks that we are accustomed to. If you don't like any, chances are you may have to make your own.
Where are we lacking?
There's no definitive "If you're going to do it, do it this way." If I want to use objects to run my data access layer, do I just make some DAOs? How do I implement them? Should I use gateways? These answers are out there, and they need to be formalized, standardized and presented to the average developer.There's a visible gap (literally), in the framework scene. In Ruby on Rails, they call this "scaffolding." It's what takes your database model and instantly transforms it into a working (though basic) application. They have it. We need it.
How do we get there? TODO: tasks for the community
*Create well organized learning resources, remembering that there are wildly different classes of CF developers. These resources should be able to reliably turn Barney Fife into a polymorphic professional. Wiki it and we will come.*Successful scaffolding, easy or not, something to make nice and simple looking forms out of DB tables (or reactor DAO metadata). Now that my CRUD typing is fairly automated (with various generators or frameworks), the forms for these should be too. Only an open source project could cover enough angles to make this useful for everyone (like an option to use cfform, flash form, qform, auto-generated or custom validation, etc. etc. etc. - there are too many options for a single-developer project).
*Combine the popular frameworks to create the uber-framework for CF (please don't use that as the name). Say "this is the standard way to make enterprise CF apps." If not literally packaging them together, there should be a 2-step process (think ant) to get them all installed and working together.
The killer app
I've been thinking about this for a few days. The "uber-framework" may consist of Model-Glue, Coldspring, Reactor, a scaffolding project, and a W3C standards-based CSS framework, (like Mollio from FarCry), or equivalents for any of these you may like. This is everything you need to create truly rapid applications. Edit 2 or 3 config files and you can have a fully working, usable web application with very basic display and edit functionality, plus it looks nice and naturally validates XHTML.From there, take the Model-Glue 2.0 ("Unity", in development) idea of included applications and insert an app much like a plugin to this 5-minute web site. Paste the files (like blogCFC or Lighthouse, I can see Ray Camden being the instant king of this, not to mention hosting these apps on cflib.org), paste the include code into your Model-Glue config file and href a link to the new app on your navigation bar. Instant plugin, instantly working. Do it 2 or 3 times and you have a full and usable web site.
Most sites that used to take 16 hours to make, now take 30 minutes. This would bring about true and simple code reuse for object oriented programming. Most of our development time would now be writing reusable, pluggable applications and finding new ways to apply them to the framework.
The CF community is coming into something big. Can you feel it? CF has a really good shot at owning the word "rapid" in "rapid application development". These are exciting times.
I appreciate all your comments - let me know what I may have left out.