The Dopefly Tech Blog

The State of Object Oriented Programming in ColdFusion

posted under category: ColdFusion on March 13, 2006 at 1:00 am by MrNate

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.

I think you've definitely captured the atmosphere. Having just returned from CFOBjective, I just want to comment that I think the framework camp could do a lot more in the way of introductory essays and tutorials. If you're new to MVC, for instance, you dont have much more than benorama's wonderful but horribly formatted MVCF.doc. Or take the Model-Glue quick start guide: any particular reason the code can't be color-coded and more printable? Remember, we're trying to sell managers on giving us time to read and experiment with this stuff. So this documentation may suffice for fellow developer geeks. But most of us have bosses with other priorities. Guess what would be ideal is if Adobe could develop its own officially recommended framework and build it into CFEclipse wizards, the language spec, etc. Anyway, nice entry Nathan.

Nice to see others are thinking in the same direction I am! I'll be looking into Mollio shortly...

-Joe

On Mar 14, 2006 at 1:00 AM Ryan Guill (ryanguill has underestimated the power of gmail.com) said:

Excellent article. I dont necessarily agree with all of it, but I do agree with your main points. We definately need to strive to not only take cf, but also these frameworks and concepts such as OO to the masses.

I posted a blog entry referencing this post here: http://www.ryanguill.com/blog/index.cfm/2006/3/14/Thoughts-on-frameworks-in-CF

You mentioned that the CF community needs learning resources, and to "Wiki it, and we will come." I started http://www.ooglossary.com for that reason. One of the largest issues with learning the OO lifestyle is learning the vocabulary. I'm hopping that ooglossary.com can turn into something that us noobs can use to start learning how to communicate in the OO parlance.

So far there's been little added to the site (thanks to Jared for what's there already...) so if anyone would like to contribute, just sign up for an account and add away :)

At CF.Objective() I released a beta of Appbooster. Appbooster is a sample/starter application that shows how to build a good enterprise app using Mach II, ColdSpring, and a service layer pattern with DAOs and Gateways. It has a basic CSS skin that can be modified. In the future it will probably support Reactor. This sounds pretty close to what you are looking for and is available as open source from my blog (link above).

We are starting a new project and could use some assistance in developing an MVC based application.

We have evaluated a number of frameworks and are leaning toward MG or Fusebox 4+.

Some details of the project are listed below:

Foresite is looking for developer to work on-site or remotely to assist in the development of a Cold Fusion 7 based e-commerce site. WE are looking to fill a full time developer position, but will consider contract work. Developer with work in a team environment on re-design project which will require implementation of html templates, code development and testing. Project requires usage of web standards techniques to develop the site. Experience with CF based frameworks such as Model-Glue or Fusebox is a plus. Use of CF components is also desirable. Foresite is located in Hollywood, FL which is midway between Miami and Fort Lauderdale.

Send resume to jobs@foresite.com

On May 13, 2006 at 1:00 AM Tom Minderson (topmind_nospam@example.com who would have preferred an address at technologist.com) said:

There is not decent evidence that OOP is better, at least not in the business domain. Most examples of betterment come from systems software, which has different change patterns than biz. And, GUI frameworks will move to declarative over time because all the widget attribute set/get's get annoying and bloaty as code. Set Theory is the next frontier, and OOP has nothing that helps it. OOP is so 90's. The faster it dies the better.

On Jul 14, 2010 at 1:00 AM Maxx (maxxtheaxe of hotmail.com) said:

If you people don't want to learn how to write software then please, do us all a favor and find a new profession.

There is nothing difficult about OOP. It's been around since the 80's and anyone who deserves a paycheck already know its it like the back of their hand.

You CF clowns (and your counterpart, the PHP hacks) are the reason the internet is riddled with unstable crap where there should be a robust engine.