The Great Coldfusion IDE Debate

I've been following with some interest the discussion regarding a Coldfusion IDE that has been raging on CF-Talk since yesterday. Ok, maybe "raging" is a bit much. How about "simmering". The thread started when someone requested that CF-Talkers get the word out about a survey being done to determine how Coldfusion Coders use development tools. I blogged about the survey a couple days ago. Of course anytime you bring up Integrated Development Environments (IDEs) and coding practices you inflame the passions of the CF faithful. In the next post or two I will try to boil down the issues into some nice categories that may prove useful for discussion. Today's issues are:

• Cross-platform Compatibility
• Why Not Dreamweaver

Cross Platform

One issue that inevitably crops up when discussing any tool or software is it cross platform compatibility. Mac users in particular are very concerned that a software product be cross platform. Actually this is painting with too nice a brush. With their usual hubris what they really mean is that it's not fair that a windows application won't run on a Mac. With torch and pitchfork passion, what they really want is an entire world of opaque white and gleaming grey (and mice that are ridiculously small and impractical) run by hip 20 somethings with black clothes.... young men who can't help putting their hands in their pockets and saying "dude"... and young women with pierced tongues, pale cadaverous make-up and overpriced handbags who role their eyes at guys in mini-vans while saying "like" this and "like that" into their overpriced (but really cool) iPhones.....uh... Ok... sorry, but you can see how these issues sort of bring out the worst in people - even the Muse.

For the record I like some Apple products in spite of their often irritating, holier-than-thou users. I can't decide if I have Apple’plexy or Apple envy. Still, there are enough PC and Apple users in the world to make being at least dual-platform a laudable goal. Until there are more Linux desktop users I can see no reason to go out of the way to create a commercial product for Linux (they would just hack the serial numbers and post it online anyway). One possible middle ground is a product like an Eclipse based IDE. Such a product would be able to run in any environment supporting the JVM. Therefore, I am coming out in support of an Eclipse based CF editor - believing it might be the best of both worlds. You might ask, "what about CF Eclipse?" I think it is a splendid project and a dandy CF Editor. I fear, however, that unless something is a commercial product the impetus to maintain and expand it falls on too few people with too little incentive. I say that with no ill will toward Rob Rohan and Mark Drew and the other community members contributing to CF Eclipse - I applaud their effort.

Issue 2: Dreamweaver and the Dichotomy of Coldfusion Coders

The second issue that is sometimes mentioned is that Adobe already has a product that it promotes as a Coldfusion IDE. Dreamweaver (DW) has been around a long time and has garnered support and wide adoption. In fact, Ben Forta points out in CF Talk thread that inspired this article that as he travels around the country about half of the Coldfusion developers he meets are using Dreamweaver. I found that surprising. Since Dreamweaver is touted by Adobe as the Coldfusion product I would have thought that the number was more like 75 percent.

For Coldfusion developers Dreamweaver is a bit like the Clintons - either adored or despised depending on which side of the fence you are sitting. Speaking for myself and most of the developers working for my company we are in the "despise" camp (for Dreamweaver, not the Clintons). What is it about Dreamweaver that is so polarizing? The issues have to do with how you approach Coldfusion development.

People arrive at the Coldfusion camp from a variety of paths but, to varying degrees, they fall into two general categories. Let's call them "Technical" and "Design". The technical folks come from some branch of Information Technology (IT). Perhaps they have worked with some other web scripting language like PHP or ASP. Maybe they were hard core programmers using Java or .NET - or maybe like myself they came from some other technical field (Network Engineering) and Coldfusion was a tool to solve some specific problem. The thing that ties them together is that see technology from a practical point of view. They are likely to have an "operational" way of thinking. When approaching a project or task they ask:

• What does it Cost?
• How long will it take?
• Is it manageable?
• Is it scalable?
• Are there alternatives?
• Is one approach better than another?
• Is there a pre-existing approach already in place?
• What are the deliverables?
• What are the requirements?
• Did I take out the trash?

On the other hand, design people come to Coldfusion from design and marketing fields. A good number of design folks actually come from print shops or marketing firms where their real job was high res graphics. Most of them have a inner eye for visual aesthetics. They are concerned with how things "look" and how the "experience" feels to the user. They often have some experience with HTML and possibly JavaScript. While technical people think in terms of "systems" and "applications" a designer might see a website as a collection of "pages". A technical person sees himself or herself as "modifying the code" whereas a designer might see himself or herself as "editing a page". Perhaps you think this is mere semantics, but the way these two types of developers see these tasks directly impacts the approach they take to coding.

Designers are much more likely to use a visual coding style while technical folks are much more likely to use a "ground up" approach that emphasizes structure. As a hypothetical example let's use a "Create/Update/Delete" tool (often referred to by the unfortunate acronym - CRUD). Let us suppose we must create a tool to do the following:

1. Add names and addresses to a database.
2. Show the users from the database in a list.
3. Edit user information and update the database.

Designers Approach: Carl Creates Forms

Our designer (let's call him Carl) starts by asking himself this question - "how many pages will I need". He comes up with a list. He will need a page with a form for adding a user, a page with a form for showing the users in a list and a page with a form for editing. Carl already has a site template. He opens Dreamweaver in design view and, using his template, he begins building his form. The form has name, phone, email, and other contact information on it. When Carl is satisfied that the form looks ok he creates another copy of it. This other copy is the one he's going to use for editing. He takes this second copy and changes the names of the button from "add" to "update" and makes a few other changes that indicate the form is really an update form. So far so good. Next he uses his template to create a page for his "list" view. Using the design view he adds a table with column headers for name, email, and phone number. He adds a few rows to the table with some sample data and styles it to his liking.

Carl now has three pages that look exactly like he wants them to look. These pages represent the three views he has imagined presenting to the user. His next task is to add some "code" to his lovely pages. First he creates a table in the database that matches the data from his form. Next, he adds a query that inserts the data from the form into the database. He adds a query that grabs all the data from the database for his "list view" and he edits his table code to use cfoutput and display the users in a list. He adds a query to get a single row of data based on the user ID (passed from the URL) for his "edit" form. He edits the "edit" form with cfoutput to contain those variables. Finally, he adds an "update" query to update the database from the "edit" form. Depending on his level of experience or sophistication (or specific requirements) he might add error handling, JavaScript etc.

My contention about Carl is this - as a designer he sees this task as reflecting his impression of how a user might experience an application. After he created his three pages Carl may have even thought to himself "I'm practically done".

Carl's Glamour Shot for the Designers Debutant Ball

A few more notes on designers. A designer is comfortable using his mouse to interact with his code. I have found that designers and coders use their input devices quite differently. Designers love those little property windows that pop up everywhere with drop downs and choices and tooltips. They actually like dragging and dropping and click select functions. These are the things that make them more productive. Since they are visual to start with, such things fit nicely into the relationship the designer has with his tools. Designers like wizards too. I don't mean Gandalf and Dumbledore - I meant the little popup step-by-step guided choices that create underlying code. Technical people often find that these things get in the way.

Now before we unpack how a technical person might approach this project I need to say one more thing about Carl. I know I said I wasn't going to touch on frameworks so let's just call this a comment on "code organization". Because Carl sees this application as three "web pages" he is much more comfortable mixing Coldfusion into his HTML. On the list page, for example, you might find the query for all the users right above the table displaying said users. You might say that Carl sees this application as three pages with some extra properties or functionality attached to them.

To Carl, adding data to the database might be on the same level as adding roll-over behaviors to the menu. In fact, Carl often blurs the line between "client side" code and "server side" code in his own mind. If you think that is unlikely, take a look at some of the email lists questions that occur from time to time about "How to access a Coldfusion variable from a JavaScript function." I'll wager that just adding that sentence to this article guaranteed another 500 visitors from Googling, novice designer types.

To put it as succinct as possible, Carl would see the above task as "Creating three forms and saving the information to a database table". Ask Carl what he was doing and he might say, "I'm making contact information forms." I would guess that about 50 to 60 percent of all the Coldfusion code that exists in the universe is written this way - largely by web designers who are using Coldfusion as a sort of performance enhancer for their web pages. Now let's discuss how the technical person might approach such a project.

Technical Approach: Warren Builds a CFC

The technical person (let's call him Warren) will spend more time outlining the "application" he is going to create. To him this is not a set of three pages working together. No indeed! This is an "application" with several "behaviors". It is designed to collect certain "data". These are the important words to Warren. He could go days without calling a web page a "page". Warren starts his project by figuring out what information he intends to collect. He then creates a table for that information in the database. He refers to this as his database "schema" (Carl rolls his eyes). Next, Warren outlines a CFC. The CFC will contain 4 methods:

• validateFormData() - a Method to check the form data to make sure it is correct.
• addNewContact() - A method that takes the form data and inserts it into the database table.
• getAllContacts() - A method that retrieves a query of all the contacts.
• getContactByID() - A method that retrieves a specific Contact.

Warren now has a database table that reflects the data concerned and methods to handle all the data interaction. His next step is to build his two forms and his list view. His approach is to use a single CFM template to load his forms using Cfinclude. He weaves a controller script together that calls his methods based on what his user has done; using form and url parameters to control the behavior of the application and to determine what is displayed.

My contention about Warren is that he starts at the other end of a project. His concern is over how things interact and behave. His thought processes center around the work that the application is supposed to accomplish. He sees the bulk of the project as creating an "application" that integrates with a "database".

Warren Just Before the Debut of "Nerds on Ice"

Warren probably did not use a wizard during the entire process. He spent his time indenting his code and determining the correct "typing" for all his variables. He might have looked for whitespace issues. He probably created an exception handler and he may have tested each column to make sure it updates and inserts correctly. Like a designer who labors over how to squeeze an extra 3 pixels into a div tag, technical folks sweat the details too - they are just very different details. I'm sure it would not surprise you if I told you that Warren's code did exactly what was advertised but it was butt-ugly while Carl's code looked fabulous but had some problems with errors.

The Muse's Caveat

Now before I use this example to comment on Dreamweaver I need to say a couple of words about Carl and Warren. Admittedly I am a Warren. In fact, as I'm writing this blog I am using Homesite and hand coding all my HTML formatting. But the truth is that there is a place for both approaches. There are, in point of fact, thousands of sites and applications on the web written by Carls that are productive and useful (the applications - not the Carls). In the task above it is quite likely that Carl would finish in 2 or 3 hours while Warren (bless him) is still pondering over his "schema". So even though I'm a Warren I understand that it takes all kinds to make the Coldfusion Universe go around. I would add that the only way to build an intuitive application that is also structurally sound is to have some of the qualities of both Carl and Warren. If you are building a team of developers you will be better served with 1 of each than with 2 of the same. Each brings something important to the table. Now let's talk about Dreamweaver.

Different Approaches Different Needs

Carl really needs something like Dreamweaver. He needs something that feels like an extension of his own aesthetic and visual approach to development. The wizards and property windows don't stand in the way of Carl. Instead they feel like a natural and intuitive way of interacting with his templates and pages. He "gets it". He loves an editor that is "appealing" and "intuitive" and has widgets like color panels and property panes.

For Warren the story is different. Why does he need a property window when he can examine the code directly? He'd rather read the help file and slog through all the options of a tag than use a wizard to obscure them. The "tag based" nature of CF is neither a disadvantage exacerbated nor an advantage mitigated by DW. Warren codes his behaviors and interactions quite separately from his HTML, JavaScript and CSS. His HTML code has some variable output code in it and little else (maybe a cfif here or there). Indeed Warren hates seeing any code that is not related to display in the HTML. He wants an editor with really good contextual help that is easy to use. He wants to control code formatting and indenting. He wants it to perform well for saving, synching and source control integration. He wants to see code on the screen - not widgets and panels. He does not want his editor doing "black box" things behind the scene that he does not explicitly ask it to do.

Dreamweaver and Paul the Apostle

Excuse the Biblical reference but it's so appropriate here. The Apostle Paul said in 1 Corinthians 9:22:

I think Dreamweaver's last two or three versions are a crack at the same thing. The DW folks have given it the attributes of a great coding IDE and the attributes of a great design tool. Unfortunately I think that many of the attributes of the design tool still stand in the way of the technical coder. I think that while most design folks have great affection and loyalty to DW, most technical folks find that it falls short. In my view DW never really managed to get past its roots as a web page editor. The whole "Dreamweaver Template" idea certainly runs counter to the ideas of code separation. DW is replete with panels, widgets and property panes that get in the way. In short, I would have to say that for the "technical" developer DW is simply not up to the task.

So I think that moving forward we should acknowledge which group of developers we are trying to satisfy as we discuss the possibility of a "Coldfusion IDE". I contend that most design oriented CF programmers using Dreamweaver are probably quite satisfied and don't know what all the hubub is about. What we are really talking about is an IDE that allows those of us who are in the other camp to work with CF in a way that matches the way we code. I will have more on this topic tomorrow as I explore the next set of issues from the thread in a follow up post. In the mean time, let's keep those comments civil - or at least funny.