There is nothing wrong with generating (or using dynamic programming to provide) default controllers, views and model functions. But why bother to write a scaffolding system that you know is going to be thrown away 60-80% of the time?
The problem isn't with scaffolding - it's a good kid with great potential. The problem is the evils of database introspection - a single technique that has put application generation back at least 5 years . . .
I mean, really, whoever came up with the idea that introspecting the database was the right way to get metadata about an application? Database schemas aren't semantically rich enough to provide the metadata required, so we end up with scaffolding that we usually have to throw away because it is way too naive for production.
But there is another way.
Use a richer metadata store (we keep a metabase in SQL server for easy reuse across thousands of projects, but XML or even hand coding a few properties into the init() methods of your custom classes will do fine for starters). Start by giving every attribute a title. (Who wants to see "LastName is a required field" in a professional production application?) Then describe its intent using a set of abstract data types so your application can automatically apply calculations, validations and transformations, so that it can nicely format date or currency displays in your lists and views and so that it can create more intelligent forms with date pickers and wysiwyg editors and drop downs with value lists rather than just text boxes and text areas for editing everything.
Of course, there will still be some work to be done. Some calculations are pretty unique, and front end layout will usually need to be tweaked by a designer, but really, lets use richer metadata so the system can generate at least 80-90% of our application code and we can put it into production rather than generating dumb scaffolding that's going to have to be done over by hand. Who's got time for that?!
Most of my next few posts will be covering the concepts and codes required to implement this utopia. Starting with self describing beans, then going on to describe my implementation of abstract data types in CF and finally looking at the practicalities of dynamic list views, item views, forms and save methods.