Adam Crump, one of the guys on my team has released a Dreamweaver MX extension he created called CFC Bean:

"CFC Bean is a command extension to generate a java style Bean implemented as a ColdFusion MX Component. You simply add the properties required for your bean, and CFC Bean will generate an init method, get and set methods for each property, and if selected getInstance, and setInstance methods. CFC Bean is very useful for creating beans for use with the MachII framework and bean work in general."

We've been using CFC Bean here for a few months now, and it's saved us a ton of time in the creation of our Mach-II beans.

If you don't use Dreamweaver, there is also a web based bean generator with similar functionality:

Jonathan Block's JavaScript bean generator

And a Homesite version by Christopher Bradford here:

Christopher Bradford's Bean VTM

Adam Crump and I are heading to San Diego next Tuesday (5/4) to visit the SDCFUG. Sean Corfield, Macromedia's Director of Architecture is giving a presentation on the use of Mach-II at Macromedia. We're particularly interested in what Sean has to say as we've recently adopted the Mach-II framework for CF Development within our company.

My team has been in the process of moving/porting a suite of ColdFusion applications to our new data center. The current apps were originally written using CF 2.0, and updated bit by bit through ColdFusion 4.5.1. We're now migrating them to CF MX 6.1 and have decided to adopt Mach-II as our framework.

We're pretty heavy users of Dan Switzer's qForms JavaScript API and have been integrating it nicely within Mach-II. One gotcha we did run into, however, was discovered by the team (Adam Crump, Jim Bambrough, Ray Ragan, and Steve Rittler). It seems if you have debugging enabled for the request scope, qForms does not work. The problem has to do with the page content being stored in the request scope, so when the page executes, it gets output normally within your view, but it also gets output in the debug code. This results in duplicate form fields and duplicate qForms code, which basically breaks functionality. Not the end of the world, but it can mislead you into believing there's an issue with qForms when there really isn't.

I took a call from our help desk last night around midnight. One of our users in Asia had called in reporting an error in one of our applications. I checked our error logs, and sure enough there was an error - an SQL error: SQL0117 - Statement contains wrong number of values. This server happens to be an old ColdFusion server still running ODBC. We're in the process of upgrading t to MX, but that's another story. Anyhow, at first, I was puzzled by the error as we hadn't made any changes to the code in quite some time. Then it hit me. Earlier in the day, we added a new column to one of the database tables used by the application in order to facilitate the upgrade. Harmless enough, right? Wrong.

Turns out the application in question had an SQL insert that looked something like this:

INSER INTO myTable VALUES('#foo#', goo, '#boo#')

Now granted this code was written about 6 years ago, but the developer who wrote it took a shortcut that came back to bite us. Instead of explicitly declaring the fields to be inserted, he or she simply expressed the values to insert. This only works when the number of values exactly matches the number of fields in the database table. In my case, the extra field we added caused the application to break. Now granted this is something that could have been caught in testing/qa, but we didn't have that luxury in this particular instance.

The moral of the story here is that in order to future proof your application, it's best to always declare the columns you intend to insert:

INSER INTO myTable (foo, goo, boo) VALUES('#foo#', goo, '#boo#')

IBM released JTOpen 4.3 today. JTOpen is an opensource Type IV JDBC driver for accessing DB2 running on the IBM iSeries midrange computer. Version 4.3 adds several bug fixes, performance enhancements, etc.

I know this has already been blogged, but I just want to mention that this year's Macromedia MAX confernece has an Open Call For Speakers. This differs from past conferences in which only persons affiliated with Macromedia could present. This open call should bring in a lot of new ideas for topics outside of Macromedia's "official" sphere of influence ;-)