Hello everyone,
First off, I’m trying to generate a discussion here, not provoke an
argument or get people upset. Please bear this in mind if/as you read
on…
To my mind, there’s 3 missing features from scaffolds that would make
them a whole lot more useful. These are:
- auto-generation of a drop-down list for inputting/updating
has_many/belongs_to relationships between tables - auto-generation of a checkbox-driven approach to inputting/updating
HABTM relationship data - auto-generation of a checkbox- plus field-driven approach to
inputting/updating HABTM relationship data, where the “middle” table
has additional fields besides e.g. id, tablea_id, tableb_id
By adding these 3 features to base Rails, my feeling is that it would
reduce the amount of repetitive coding required by probably 80%. I
understand that there’s a reluctance on the part of the core Rails
team to extend scaffolds, but I really don’t understand the reason for
this reluctance.
Consider the first “missing” feature: auto-generation of a drop-down
list for has_many/belongs_to table relationships. I can’t think of a
single database application I’ve ever worked on that didn’t have
multiple tables with such a parent/child relationship; indeed, if an
application didn’t have such a relationship between tables, there
would probably be a strong case to go without a database and use e.g.
flat files instead. Every time I’ve put together a Rails scaffold,
I’ve had to go in and tweak several _form.rhtml files to add a
drop-down list in place of a text field. It takes me only a minimal
amount of time these days, but the first time I had to do it I
struggled because it wasn’t intuitive (who’s going to guess that the
key function is named ‘options_from_collection_for_select’)?. With
all the speed, agility and simplicity that Rails brings to
Web/database development, it simply doesn’t make sense that the
drop-down list isn’t auto-created as part of the scaffold.
The second “missing” feature - auto-generation of checkboxes for HABTM
forms - is not quite as straightforward. Where there’s e.g. 1000
records in one of the two tables, having to wade through 1000
checkboxes on a single form is hardly ideal. However, in the case of
scaffolds I’d regard this as a corner case, and ignore it - build a
scaffold that supports HABTM data entry and let people tweak it
if/when they hit this issue.
The third “missing” feature - auto-generation of HABTM forms where
there’s additional fields in the “middle” table - is probably a tricky
one. I regularly struggle with how to present this data in a form,
and normally have to come up with a custom solution for each time I’m
faced with this scenario. However, a scaffold solution is still
possible that would serve as a baseline for customisation.
Other people are building ‘standard’ add-on solutions for these 3
scenarios, but they haven’t been incorporated into base Rails and it
seems like there’s a general reluctance on the part of the core team
to extend scaffolds in such a manner. Please tell me if this
reluctance is only my perception and not the truth… The problem
with bolt-on “scaffold extension” solutions is that the bolt-ons may
break as Rails develops over time; there will be a long-term support
requirement for these bolt-ons that (at present) the core Rails team
won’t be providing.
My reasons why these features should be included in base Rails are
fairly straightforward:
- these 3 solution patterns crop up regularly, with the first 2
occurring extremely often. Rails’ focus is on DRY, yet solutions to
these issues need to be recreated over and over again for every Rails
app - like it or not, a lot of people are basing their final Rails
solution on scaffolds. While there may be a perceived lack of
elegance about this, the fact is that it’s very productive to start
with basic scaffolds and extend/tweak them to solve a large number of
business problems - I work as a consultant to many large corporates. I’ve encountered a
huge number of client/server database apps that (strategically)
should be migrated to a Web user interface. There’s no question in
anyone’s mind that they should be given a Web interface, but the
primary reason why this isn’t done is cost; at present, it takes too
long and costs too much money to migrate all these
often-tiny-but-highly-critical MS Access/SQL Server/Oracle apps to a
Web interface. By putting the above 3 features into scaffolds, Rails
would be ideally placed to become the solution of choice for all these
corporate database apps
All that said, I’m extremely grateful for the existence of Rails, and
it’s both made my life easier and expanded the scope of what I can
profitably deliver to my customers. It just seems that, with a
relatively small amount of scaffold enhancements, it could be so much
more useful.
I’m really interested in others’ thoughts on this issue, so please speak
up.
Regards
Dave M.