# Missing scaffold features **URL:** \ **Category:** Rails\ **Created:** [November 30, 2005, 11:28pm UTC](https://www.ruby-forum.com/t/missing-scaffold-features/49180 "2005-11-30T23:28:08Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![monch1962](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ee59a6/32.png) [@monch1962](https://www.ruby-forum.com/u/monch1962)\ **Post date:** [November 30, 2005, 11:28pm UTC](https://www.ruby-forum.com/t/missing-scaffold-features/49180/1 "2005-11-30T23:28:08Z")
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. ---
**Author:** ![monch1962](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ee59a6/32.png) [@monch1962](https://www.ruby-forum.com/u/monch1962)\ **Post date:** [December 1, 2005, 1:29am UTC](https://www.ruby-forum.com/t/missing-scaffold-features/49180/2 "2005-12-01T01:29:20Z")
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 ---
**Author:** ![monch1962](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ee59a6/32.png) [@monch1962](https://www.ruby-forum.com/u/monch1962)\ **Post date:** [December 2, 2005, 6:20am UTC](https://www.ruby-forum.com/t/missing-scaffold-features/49180/3 "2005-12-02T06:20:55Z")
On 11/30/05, David M. [removed\_email\_address@domain.invalid](mailto: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/HowToExtendScaffolding](http://wiki.rubyonrails.com/rails/pages/HowToExtendScaffolding) 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.