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

6 Responses to “Scaffolding has changed in Rails 2.0: Has it become un-Agile?”

  1. Scaffolding has changed in Rails 2.0: Has it become un-Agile? Says:

    […] RK Web Technology Resouces News and More wrote an interesting post today onHere’s a quick excerpt […]

  2. Bookmarks Tagged Agile Says:

    […] bookmarks tagged agile Scaffolding has changed in Rails 2.0: Has it becom… saved by 1 others     sakubatzumatsu bookmarked on 01/02/08 | […]

  3. David Lynch Says:

    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…

  4. David Lynch Says:

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

  5. steven Says:

    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.

  6. dzonekl Says:

    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

Leave a Reply