John Farrar on the COOP ColdFusion Framework
COOP is the new kid on the framework block, and was designed to help developers get full-featured prototypes up and running quickly. Here, John Farrar shows off his baby.
SitePoint: John, can you give us your elevator pitch for COOP?
The idea behind COOP is "inspirational simplicity" — the separation of the designer’s presentation from the developer’s logic. The technology starts with powerful prototyping and finishes with "preDOM" object coding and clean versatile logic. The API makes it possible to write code with features not standard in the built-in ColdFusion tags.
SP: Okay, can you tell us more about the main features?
We believe COOP is simple to learn and code. You won’t have to go out and buy a book to understand how to build good applications using this framework. Of course, you still can do that, but writing good code shouldn’t require making things so complex that a CF developer will get stuck. This simplicity means you can get faster ROI and bring developers up to speed without enrolling them in "book of the geek" club just to keep up.
One of the great features of COOP relates to the proper encapsulation and separation of design and program logic. One of the things that’s causing a big stir in the AIR/Flex community is the Thermo project (which allows designers to create interfaces for Flex applications in a visual environment). Regardless of how it’s done, this lets the developer and designer work on the same pages without touching each other’s code — or without breaking each other’s code. They both work on separate files, but they can work in parallel. It takes more than CSS to properly separate the design from the logic, and COOP makes the task incredibly easy. Let me explain how.
The user requests a page. The page contains ColdFusion/COOP markup code in tags. Before the code is run the co-processor, a CFC that runs in parallel with the page is called to manage the logic. This is a controller and it allows the page tags to be treated like objects, which means you can set the data and any attribute other than the ID of tags from the co-processor. The co-processor is called again after the markup code is executed, and then the content’s sent back to the user. So the markup forms the view portion of the request. If your model (data) is needed, it’s called through the co-processor. Yes, for those who care about such things, it does work as an MVC methodology.
Also, the framework is very flexible. We strongly promote prototyping. When developers are prototyping, they’ll often bury lots of "bad code" in the markup page — code that we’ll re-factor into the co-processor later. It’s okay to do this while we’re prototyping. The process could be compared to the logic of not creating an engine block mold just for a prototype of a car. It means we can use all the attributes that we’ll be setting in the co-processor right inside the markup. Sure, it’s not elegant, but it’s much more productive during the prototype phase! This is how COOP allows developers and designers to achieve higher productivity — designers can pass in a simple string list of data for the prototype’s use, and when the prototype is approved, the developer can replace or override the string list with real data from the co-processor.
Last on the top features list would be the value of using COOP to integrate AJAX libraries and encapsulate custom markup and processing. COOP is extensible and it’s open source. There are templates for building your own tags. There are features of the core CFC co-processor and some additional CFCs that make integration easier still. Bottom line is that this is a great way to package AJAX libraries into ColdFusion.
SP: How did COOP come about? Why was it created it?
Well, we have the same bad history as most programmers. Once upon a time we programmed with procedural programming. After that, other companies came to SOSensible and asked us to pick up the pieces of other projects that were created with procedural programming. The simple concept doesn’t require spaghetti code, but it just starts to happen. We also wanted to help many of our customers who don’t have staff trained in the finer aspects of design patterns and every other thing that makes a developer a super-geek. We wanted to leave projects a .NET or PHP or Java or common CF developer could jump right in and "get".
SP: How are you involved?
I’m the creator of COOP. I began programming software around 1977. I have worked on many platforms and with many code languages. Perhaps this broad view of development drove me to provide structure without complex, hard-to-understand coding methodologies. Please don’t misunderstand me — I think design patterns work great. It just isn’t going to be the way most guys write code.
The pastor who performed my wedding ceremony said, "Greatness is profundity wrapped in simplicity," and to me, this is what COOP is about. It was actually designed more for my company. It was designed so it could be used to replace single pages for clients with messed up sites and to build entire sites that are a pleasure to build and revisit. We thought it was so exciting we just wanted to share it with the rest of the ColdFusion world.
SP: When should a developer seek out COOP? What does it have going for it?
Well, as a developer, wouldn’t you like to program the presentation elements like they were objects? This means you can do things like assign a data collection to the ID of a markup page element from the business logic, then set the default or current ID of that element. This is what we mean by "preDOM". Let’s say we had a group of radio buttons and we used the
<coop:radiobuttonlist id="idOption"/> tag on the markup page. In the
onPageStart() method in our coprocessor, we could set the data for the element using a using the api domain variable
_init. It would look like this:
_init.idOption.data = getOptions(). Internally, COOP tags can handle things like radio lists. They smartly spot if the data is a list, array, or a query-based recordset, and process it accordingly.
There are also advantages from the designer’s viewpoint, which works out to be an advantage for developers because it creates a better work environment. Designers we interviewed have told us over and over again that they don’t like to program. The issue is that even when they don’t program an automated web application they have to wade through our code without messing it up. COOP lets designers concentrate on the presentation while we concentrate on delivering the content and business logic.
SP: What are the pre-requisites for using COOP? Is there any prior knowledge that would help new users? Does it use any other frameworks that could simplify or complicate things?
COOP will work with other frameworks but it doesn’t require any. You can use COOP inside other frameworks, and use things like database frameworks or IOC frameworks inside of COOP. The bottom line is that it integrates and allows integration.
SP: What sets COOP apart from other frameworks?
If you like ColdFusion, we think you’ll gravitate to COOP. We like to say COOP thinks more like ColdFusion than any other framework out there. This doesn’t take anything away from many other great works out there — in fact, we would like them to get the concept and create some of the same things for their users also. It’s probably the easiest framework if you wish to integrate an Ajax library and do it ColdFusion style. Check out some of our ICE libraries and you’ll see the simple power of Ajax libraries mixed with object-like interaction of the markup. The tags can be updated. New tags can be added. There’s no need to wait for the next version of ColdFusion to ship! This is a truly open-source solution that works as well on shared hosting as it does in the enterprise.
SP: Are there any great examples of COOP "in the wild"?
Well, we don’t have any Amazons or Googles just yet…
SP: Sure. Well, can you give us look at some of the code?
No problem. Here’s how we could build a simple segment of a COOP page.
OLD SCHOOL (Procedural code at its finest)
<select id="myFruit" name="myFruit">
<cfloop list="apple,blue berry,cherry,mango,orange" index="iFruit">
STAGE 1: Prototype
We're passing in a list but coop can spot
if the data is a list, array of structures or
a query and knows how to handle that internally.
STAGE 2: Refactor
(in the word of one developer, the markup page gets "elegant")
(the co-processor page now adds this...)
/* The init is the base for the page object modeling.
* The myFruit is the ID of the object we are programming
* before creating it. A.K.A. preDOM.
_init.myFruit.data = "apple,blue berry,cherry,mango,orange";
STAGE 3: Enhance
/* Enhancing the code to real data and control
* by setting attributes in code rather than
* inside the markup.
_init.myFruit.data = getFruit();
_init.myFruit.valueField = "fruit_ID"; // id field in recordset
_init.myFruit.displayField = "fruit"; // fruit name in recordset
There is much, much more that has been built in, and simplified in, COOP. Programming sites with this technology and lets designers do their job without the if…then…else, loop, and all that stuff we developers enjoy. It lets us control the page without touching the design, so we don’t get blamed quite so often for messing up the look and feel! And if you’re working on a site alone, it lets you concentrate on one thing at a time, which is great.
SP: What about licensing, community, support, and documentation?
Our licensing model is listed on at http://coop.riaforge.org/ — basically as COOP is our creation, and there’s no liability for its use, others are welcome to use it for any project. If users have any questions, they can just ask, and we’ll let them know how it works in your scenario. For community support, we have a Google group set up, and initial documentation is available from our site.
SP: What’s coming up in the future for COOP?
Firstly, we’re working on version 2.0, but we’re going to do a 1.5 release, paving the way. The changes include simple things like a full Unit Test on the back end to test all of the COOP CFCs and tags. We’ve re-factored our code base so that it’s more portable, and isn’t locked to the root of the site. We now handle structure of arrays, and it’s possible to use XML as a data source. On the documentation front, we’re working on YouTube videos for each tag and aspect of the platform.
In the future, we’ll implement ICE libraries (TinyMCE, jQuery Grid, Flot, YUI Editor, and much more to follow). These are COOP-style libraries ("ColdFusionified", if you like), collections that have been re-factored to work more easily and integrate more effectively through the power of ColdFusion.
SP: Where can people find more information about COOP?
Our initial docs can be found on our site — they should get most people started.
Again, check out the upcoming YouTube videos to get more detail on how to use all the great features of COOP. If you’d like to get in on the 1.5 beta, go to our forum, which is located at RIAForge. There’s also an online presentation on Charlie’s UGTV from the time when the product went to version 1.0.