In Defense of Dynamic Scaffolding ("scaffold :model")

Dynamic scaffolding as a concept was popularized by Rails, but hasn’t
been recommended since shortly after it was included with Rails. On the
surface, dynamic scaffolding seems like a good fit with Rails
philosophy. It’s simple to use and is very DRY (much more so than
generated scaffolding). However, dynamic scaffolding is currently
deprecated and will be removed in Rails 2.0 (though you’ll be able to
get it with a plugin).

What is wrong with dynamic scaffolding? Well, here are some criticisms
of it:

  1. It doesn’t do X (e.g. associations, search)

This is a problem not with the concept of dynamic scaffolding, but with
Rails very basic implementation of it. Dynamic scaffolding in theory
can automatically generate any code that you would type in manually, if
the dynamic scaffolding code itself is modified to support it. In many
cases, it is more work to modify the scaffolding code than it is to
manually code what you want. This is true in most cases where the
modifications you would want to make would only affect a single model or
action. However, if you want to add a similar action for many different
models, modifying the dynamic scaffolding code may be easier, and the
possibility for reuse is a lot higher.

I’ve found that pretty much everything I’ve wanted to use scaffolding
for, I’ve been able to modify the scaffolding code to dynamically
produce the output I want. Just because scaffolding currently doesn’t
do something you want doesn’t mean that it can’t.

  1. It’s too magical

Yes, it is magical, possibly more so than most of Rails. However, it
automatically generates much more code than most of the magic features
in Rails, so of course it will appear more magical. Of course, Rails is
open source and anyone can look behind then magic if they so choose
(that’s how I got started hacking Rails internals). Looking at how the
magic features in scaffolding work is a good way to learn how Rails uses
Ruby’s metaprogramming techniques.

  1. It makes things appear too easy

True, but if used correctly, things actually are much easier. If you
want a simple admin interface to a 50 model database, you are probably
much better off using some advanced scaffolding than creating individual
forms for all models. Not only is it simpler to create the forms using
scaffolding, it is probably easier to maintain them.

  1. It causes “scaffold withdrawal”

“Scaffold withdrawal” being the “cold, clammy realization that
scaffolding can’t cut it forever and we don’t know what to do next” [0].
Certainly, even in the best case, scaffolding is not going to solve all
of your problems (though I have a production intranet application where
I work that is 80-90% scaffolded code). But even in the best case
scenario, scaffolding won’t solve all of your problems, and developers
using scaffolding should realize that (I think most do).

  1. It shouldn’t be in core

I agree with this. Plugins were added to Rails after scaffolding, which
is probably why scaffolding wasn’t a plugin in the first place. Moving
it to a plugin, similar to what was done with pagination, was the right

If you find the tedious process of creating form after similar form
unrewarding, try one of the advanced scaffolding packages and see if
they can work for you:

  • Scaffolding Extensions [1]
  • Streamlined [2]
  • ActiveScaffold [3]
  • Auto-Admin [4]

I haven’t tried any but the first (which I wrote), but hopefully the
developers of the other scaffolding plugins can chime in with their
thoughts. Also, if you are a user of any of the above plugins, please
reply and state your reasons for using the plugin and your experiences
with it.



I have been using Active Scaffold for some time now (2-3 months). I
am very happy with the default UI and behavior in most ways. As we
discussed in the BOF at RailsConf 2007 there will always be a 5-10%
gap between any user’s needs and a generic framework like AS or Rails
for that matter. I have found Active Scaffold very amenable to
adaptation. It provides many hooks for easy customization, and is
open source for those less common cases. Using ruby to apply patches
to an open source framework makes that last 1% so much easier than any
other environment! There are even starting to be plug-ins to AS
indicating there is enough function there to be worth extending in a
general way.

I chose Active Scaffold in part because it was the first one I came
across, but also because it keeps coming out better in evaluations I
do. I did not like the Streamlined UI behavior at all. The UI did
not feel good to me. I did not use Hobo because I do not want to
learn yet another tag language. I have not looked at the other 2 you
mention, but I am getting vested enough in AS that I will probably not
change it out for the current project, and even later projects will
most likely use it as I have developed a good working relationship
with the code and would not want to invest that time again without a
big pay off.