I'll jump on the plugin. Should I commit it to the official plugin repository or just to my own?
Just finished rolling the scaffolding plugin. I would deprecate scaffolding in core and point people to install the plugin instead. The plugin will then override the annoying deprecation notice.
The plugin is a direct port, no new enhancements, even though it could use some. O, and for the first time, scaffolding tests!
http://dev.rubyonrails.org/attachment/ticket/7700/scaffolding_plugin.diff
I'm not maintaining it anymore, but I did create a full dynamic resource scaffolding plugin, last year, that you are welcome to borrow from, if there is anything worth it in there: Google Code Archive - Long-term storage for Google Code Project Hosting. . I followed the existing scaffolding code (that existed at that time, obviously), as closely as I could.
After making that plugin I started to come around to the core team's views on the shortcomings of scaffolding, but I still don't like the lack of DRYness of how much shared code there is between my controllers. Maybe the generator should create a shared restcontroller to inherit from? Basically an updated version of http://geekonomics.blogspot.com/2006/07/crud-and-shared-controllers.html That allows for DRYness with the flexibility to easily override, customize, and extend.
Not sure if there is any interest in doing so in core, so I went ahead and did so for my own use, but it's MIT licensed, so have at it. I just think the move to REST simplifies things enough that they can be DRYed out even more.
http://code.google.com/p/restcontroller/ http://www.timocracy.com/articles/2007/04/03/dynamic-scaffold-resource-is-dead-long-live-restcontroller