So, just to recap the flow of this conversation for myself: a) We, as developers *of* Rails (or at least those who lurk here), realize that we're not the primary target of scaffolding. So, while it could be moved to gem for pros, it would be hard on new developers if it wasn't baked in and highlighted in guides/docs
b) People who have spent time teaching Rails to new folks have chimed in saying they don't tell people to about scaffolding or, if they show people it exits, it's with a hand-wavy caveat: don't use this yet, since you don't know what it's all doing. c) Folks who haven't taught Rails (or at least didn't mention it) say the teaching folks thinking about it backwards: "After you know, using it is a cheap trick, before then it's a useful way to get an example and dig in." d) Other people counter saying "no idea about the n00bs, but I use scaffolding so much that I have custom scaffolds to match my coding style" Thoughts: * Scaffolding is less useful to new Rails developers – at least those with a learning resource of some kind – than we assumed * Scaffolding is more useful to pro Rails developers – especially with personalization – than we assumed Separating/keeping the scaffold generator might be a good Github ticket-based question for the larger Rails community. Then we'd get a feel for how many people use it and how they're using it. If the answer is "hardly anyone and many of those people use customization" it might indicate that scaffolding generation would be a good 3rd party project: scaffold users could give scaffolding the loving care it deserves. The notion that it's a tool for beginners might be holding back some truly excellent growth If the answer is "almost everyone and without customization" then it should remain as part of core. I'd *still* argue it should be moved out of the Getting Started with Rails guides If the answer is "never use it now, but it was invaluably helpful when I was learning" then the suggestion of making it a more incremental generator that can build the entire REST pattern over time by running it multiple times would be awesome. I think this would also jive better with the TDD/BDD threads floating through Rails. I've always found it odd to talk TDD and then generate a hundred lines of untested code. Incremental scaffolding would generate only the routes, models, migrations, controller/action, spec/test files and context/describe blocks, for the specific thin slice of Rails you're currently developing. Running it a second time with new arguments would slowly build a Rails app with guidance. e.g: $ rails g scaffold Person - empty model - migration to create table - empty model test file possibly we could run tests so after generation there's a clear next step: write tests $ rails g scaffold Person new create - model exists - no migration changes needed - empty resource controller - resource controller spec create with context for new and create - route added: "resources :people, :only => [:new, :create]" - empty view for new, create running later: $ rails g scaffold Person name:string birthdate:date - model exists (although maybe attar_accessible :name, :birthdate is added and warning about mass assignment) - migration created to add name and birthdate attributes - form partial gets name/birthday fields appended - model test file gets new empty context/describe blocks for added attributes - no controller or route changes - @trek On Thursday, March 8, 2012 at 8:26 PM, Mark Ratjens wrote: > My first gut feeling was "kill it, kill it". But then, I am the kind of > person that tends to spring-clean then regret throwing away too much. > > The Wow factor is what got me into Rails in the first place, even though I > quickly refactored the scaffold code I had generated ... and never looked > back. Scaffolds help lower the barrier to newbies. I may not have jumped out > of Java into Rails as quickly if that barrier was higher. But that was 2005 > ... > > So I think it's an issue of education. Trainers, mentors and senior devs need > to 'pace' newbies. > > 1) Show them scaffolds. Let them go 'wow.' > 2) Develop an example to the point where scaffolds become problematic. Let > them grok the cul-de-sac they're in. > 3) Fix the problem by showing them how controllers are really developed. > > You can't go directly from step 1 to step 3, because many of them will still > be basking in the glow of the wow. The won't be attending to what you're > trying to show them. As some have said, their mental models could be > distorted. > > Mark Ratjens > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/rubyonrails-core/-/MxELMN9M7OYJ. > To post to this group, send email to rubyonrails-core@googlegroups.com > (mailto:rubyonrails-core@googlegroups.com). > To unsubscribe from this group, send email to > rubyonrails-core+unsubscr...@googlegroups.com > (mailto:rubyonrails-core+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
