This is the mail that I sent to Rails-list which describes my issues around the Rails scaffolding in Rails 2.0. Extensive debugging information can be found in my diagnostic research post.
Hello,
I’ve read the (many) re-posts about problems around scaffolding in Rails 2.0 and have followed a number of tutorials and fully understand “how to scaffold” from a technical perspective, but I don’t understand the mindset of how to use the new scaffolding. It seems like a productivity- / agility- regress and I’m thinking I may have failed to properly grok the new setup. In the interest of full disclosure, I’m coming back to Rails after being in other toolkits for about 9 months.
Thanks to the intrepid work of Sean Lynch at ( http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html ) I found a tutorial that would familiarize me with the raw “how to scaffold” material.
I followed his tutorial’s step of:
“ruby script/generate scaffold Movie”
Great! From that point I filled in the “columns” in the migration as I had done in Rails 1.x. All I should need to do is run “rake db:migrate” and try adding a new record via the dynamically-created view.
When I started the server and navigated localhost:3000/movies I had the “create new” button. When I pushed that button there were no text widgets to enter despite having defined the columns that corresponded to said widgets having been added to the migration ( I have a lengthy blog post about how my diagnostics went, for anyone else’s edification ). In short the scaffold that had been created knew nothing of the columns I had added in the migration and, as such, the ‘new’ view had no widgets.
This struck me as well, wrong. On Sean’s post another user confirms the same experience. I have tried it with sqlite3 / mysql / postgres connectors.
Research showed that the scaffold had remained static relative to the time that I had done the original aenemic invocation. Per “script/generate scaffold —help”:
./script/generate scaffold post` # no attributes, view will be anemic
To fix this I had to re-issue the script/generate command with all the attributes in “final draft” mode ( “script/generate scaffold movie title:string text:description one_sheet_url:string” ) and then over-write the old templates ( output stored below, for legibility, Fig. 1).
The solution implies:
- You have to get the script/generate command’s “attributes” arguments perfect at time of creation OR
- You do this overwriting thing that I describe below.
As I recall Rails 1.x’s dynamic scaffolding allowed us to use a scaffold flexibly strictly based on migrations and rake db:migrate. This flexibility allowed us to “sketch” ideas very rapidly. Or is it considered a “Good Thing” that you get a “perfected” “generate scaffold” command at some point? If so, what’s the reasoning? Am I missing some sort of rake command that “refreshes” the scaffold templates?
Based on the comments at Sean’s site and some of the questions in the comments to DHH’s Rails 2. announcement I think there are others grappling with this quandry as well. Can anyone help?
Steven
Fig. 1
bash-3.2$ script/generate scaffold movie title:string text:description one_sheet_url:string
exists app/models/
exists app/controllers/
exists app/helpers/
exists app/views/movies
exists app/views/layouts/
exists test/functional/
exists test/unit/
overwrite app/views/movies/index.html.erb? (enter "h" for help) [Ynaqdh] y
force app/views/movies/index.html.erb
overwrite app/views/movies/show.html.erb? (enter "h" for help) [Ynaqdh] y
force app/views/movies/show.html.erb
overwrite app/views/movies/new.html.erb? (enter "h" for help) [Ynaqdh] y
force app/views/movies/new.html.erb
overwrite app/views/movies/edit.html.erb? (enter "h" for help) [Ynaqdh] y
force app/views/movies/edit.html.erb
identical app/views/layouts/movies.html.erb
identical public/stylesheets/scaffold.css
dependency model
exists app/models/
exists test/unit/
exists test/fixtures/
identical app/models/movie.rb
identical test/unit/movie_test.rb
skip test/fixtures/movies.yml
exists db/migrate
Another migration is already named create_movies: db/migrate/001_create_movies.rb
January 2nd, 2008 at 7:27 pm
[…] RK Web Technology Resouces News and More wrote an interesting post today onHere’s a quick excerpt […]
January 3rd, 2008 at 3:47 am
[…] bookmarks tagged agile Scaffolding has changed in Rails 2.0: Has it becom… saved by 1 others sakubatzumatsu bookmarked on 01/02/08 | […]
January 5th, 2008 at 7:14 am
Rails 2.0 Scaffolding…
I’m learning Ruby on Rails starting with 2.0. This is occasionally problematic, as it was only released a few days ago, and the tutorials are still all for 1.2.
So, to help others, something not mentioned in the release notes, which causes error…
January 5th, 2008 at 7:18 am
I ran up against the new scaffolding while following the official tutorial, and had to work out for myself why “scaffold :Foo” in a controller was causing so many problems.
Having tracked down the new way of doing things — which is completely unmentioned in the release post, for some strange reason — I think I like it better.
Generating your controller files and templates gives you a great jumping off point. There’s now far less effort involved in moving from a scaffolded site to a slightly customized site. This seems to me more “Agile” than the magic “scaffold :Foo”.
January 5th, 2008 at 6:38 pm
I pointed out on David’s site that under Rails 1.x you had a great means for sketching with the dynamic scaffold and migrations and when you wanted to ‘etch in stone’ — you could use the scaffold generator script.
I can roll with the punches, I just miss the flexibility.
September 19th, 2008 at 11:51 am
Hi,
I just discovered the exact same as you describe. Rails 2+ is a step backward from a scaffolding perspective at a first glance. On the other hand, if you have the views generate with all fields, you also get a lot of fields you might not want in your UI. bottom-line. A little bit more work……
Cheers