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:
- 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.
- 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.
- 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.
- 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).
- 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
move.
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.
Jeremy
[0] slash7 with Amy Hoy » Blog Archive » The Fall from Scaffolding
[1]
http://wiki.rubyonrails.org/rails/pages/Scaffolding+Extensions+Plugin
[2] http://www.streamlinedframework.org/
[3] http://www.activescaffold.com/
[4] http://code.trebex.net/auto-admin