Philosophy of scaffolding
I’ve been having a look at Ruby on Rails again, now that version 2 has been released. Generally, I like what I find in this new release. Rails is opinionated software - it isn’t afraid to commit to an approach, rather than trying to be ‘all things to all men’. In a way, this is a continuation of the convention over configuration philosophy which underpins much of Rails’ design. For example SOAP services support has been moved out of the main release and made available as a plugin, while Rails has been refactored to support ReST functionality by default via ActiveResource.
One major change in Rails 2 does strike me a somewhat odd though: the decision to remove the ‘dynamic scaffolding’ from Rails 2 removes one of the very things which make Rails attractive to me. Dynamic scaffolding is the functionality which, in a Model View Controller (MVC) framework (like Rails), allows the developer to prototype the models and have controllers and views which support basic create, update and delete (CRUD) operations generated at run time. I have used Rails successfully as a very rapid prototyping framework, knocking up a basic web-application in real time, with the ‘customer’ sat beside me while I did so. Rails was the first tool I found which allowed me to do this - and it worked brilliantly, in part due to dynamic scaffolding. The thinking behind the removal of this, to my mind, extraordinarily useful functionality is unclear to me. It is explored by Steven Harms in his post, I s the rails 2.0 scaffold system philosophically ( not technically? ) broken?.
This post generated quite a long comment stream - much of which seems to miss the point and go off on tangents about what should or should not be ‘allowed’ to change in a major upgrade. Other comments point out that the developer can’t learn Rails properly if they are using dynamic scaffolding because the code is invisible to them. Somehow it doesn’t seem to matter that part of the appeal of Rails is how much you don’t have to learn. Martin-234 asks, reasonably:
Many older tutorials (and books) suggested a method of working models and relations like: generate model, scaffold, migrate, check, migrate, check… (e.g. the original blog-video and the depot tutorial) […]What is the new preferred way of working?
I’m with Martin. While I understand that experienced rails developers might eschew dynamic scaffolding altogether, it has been a major factor in attracting new developers to Rails to date - I’m puzzled that it would be left out altogether now.
This story has a happy ending however. Having a look around, I found reference to the Scaffolding Extensions Plugin for Rails. Originally designed to augment and extend the existing dynamic scaffolding in Rails 1.x, it occurred to me to try it as a replacement for this lost functionality. Having installed it I immediately hit the following error:
ActionController::InvalidAuthenticityToken in CrudController
I mailed the developer, Jeremy Evans, with this issue and as much detail about my environment as I thought could be useful, and I’m pleased to say that I got an exemplary response with an explanation within 6 hours, followed by another response a couple of hours later with a patch attached to the message. (I won’t post the patch here as Jeremy is working on a fix for the codebase right now). Havin followed Jeremy’s instructions and applied the patch he supplied, this plugin is now working for me - which means I have dynamic scaffolding back, and better than before!
First-class support for open-source software - I urge any readers missing a dynamic-scaffolding capability for Rails 2 to look no further than Scaffolding Extensions Plugin for Rails.
Update: the the Scaffold Extensions plugin has now been updated (rev 89) to fix the issue I reported above.
comments powered by Disqus