Forum: Ruby on Rails Missing scaffold features

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
monch1962 (Guest)
on 2005-12-01 00:28
(Received via mailing list)
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.
jdell (Guest)
on 2005-12-01 02:29
(Received via mailing list)
David M. wrote:
...
> 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
...
> I'm really interested in others' thoughts on this issue, so please speak up.

I'm a rails newbie working on my first application, and I'd love to see
these features in scaffolding.  If these features existed, I would
certainly use them and rewrite them (eventually), but it would get me
that much further and help me understand the proper way to implement
these kinds of code constructs.

John
jeremyevans0 (Guest)
on 2005-12-02 07:20
(Received via mailing list)
On 11/30/05, David M. <removed_email_address@domain.invalid> wrote:
> 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

See http://wiki.rubyonrails.com/rails/pages/HowToExten... for
an example of how to do this.  The code on that page should work for
0.13.1.  I have converted the code on that page to a 0.14.3 plugin,
and added some features that make administration easier, but I haven't
released it yet (still testing it).  Let me know off-list if you are
interested in it.

> - auto-generation of a checkbox-driven approach to inputting/updating
> HABTM relationship data

Above link also has a section on HABTM, though it uses select boxes
instead of checkboxes.

> - 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

HABTM join tables that have extra attributes should really become full
models that you can then scaffold (rather easily using belongs_to
scaffolding).  Don't forget that you can create a separate model for
the scaffolding and still use HABTM in the other models.

> 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.

I use extended scaffolding for the almost all administrative forms on
the web sites I develop, and I'd say 80% is a conservative estimate of
time saved creating forms.  The only reason I can think of that Rails
doesn't include better scaffolding is that it has not been a problem
that has affected the Rails core team members.

> 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.

Because extending scaffolding mucks with the internals of Rails (much
of which is undocumented), it is likely to break on upgrades to Rails
(as the code at the above link did).

> 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 agree completely.
This topic is locked and can not be replied to.