Hello friends, It''s been fun having the scaffold generator exist as a part of Rails since The Beginning Of Time, but I think its time is now up. It has been abused time and time again, and most often leads to confusion amongst people who are new to Rails. This confusion happens when a user first generates a scaffold and sees that it is good. They can perform CRUD actions on a resource using one command?! WOW! Then they try to modify the scaffold and run into problems. First of all: how do they add an action to the controller? Do they need to run another command? How do they then define a route for that action? A template? If they were to *not* use the scaffold generator from the beginning, I believe they would have less confusion. They would know how to add another action to the controller and a template for that action because this would be how they''re doing it from the start. Learning how to define a route for a new action in the controller is something easily learnable by reading the routing guide. I think that we can fix this problem in one of two ways, the latter more extreme than the first one. The first way is that we completely change the Getting Started Guide to simply *mention* the scaffold generator, but then show people the "correct" way of generating a controller (rails g controller) and adding actions to it one by one, adding a model as its needed, and using similar practices to how you would do it in the "real world". The second way, and sorry if this sounds a little extreme, is to completely remove the scaffold generator from the core of Rails itself. This means that there wouldn''t even be the option to run the scaffold generator for newbies. You could then extract this out into a gem if you *really* wanted people to have the option for it. However, if this path was taken it should be made clear that this is not the "sanctioned" way to create controllers. Thoughts? -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
I would be in favor of either of these two options. I imagine extracting and gem-ifying the controllers would be a hassle, but then the default path for setting up a new view and controller action would require the user to think about what they are doing rather than just observe the magic. Unfortunately, I think that even if we were to extract out to a gem that every non-official tutorial and book would just tell users to add "rails_controller_generators" to their gemfile as the first step, and the intended goal of this work would be completely bypassed. On Thu, Mar 8, 2012 at 1:30 PM, Ryan Bigg <radarlistener@gmail.com> wrote:> Hello friends, > > It''s been fun having the scaffold generator exist as a part of Rails since > The Beginning Of Time, but I think its time is now up. It has been abused > time and time again, and most often leads to confusion amongst people who > are new to Rails. > > This confusion happens when a user first generates a scaffold and sees > that it is good. They can perform CRUD actions on a resource using one > command?! WOW! > > Then they try to modify the scaffold and run into problems. First of all: > how do they add an action to the controller? Do they need to run another > command? How do they then define a route for that action? A template? > > If they were to *not* use the scaffold generator from the beginning, I > believe they would have less confusion. They would know how to add another > action to the controller and a template for that action because this would > be how they''re doing it from the start. Learning how to define a route for > a new action in the controller is something easily learnable by reading the > routing guide. > > I think that we can fix this problem in one of two ways, the latter more > extreme than the first one. > > The first way is that we *completely change the Getting Started Guide to > simply *mention* the scaffold generator*, but then show people the > "correct" way of generating a controller (rails g controller) and adding > actions to it one by one, adding a model as its needed, and using similar > practices to how you would do it in the "real world". > > The second way, and sorry if this sounds a little extreme, is to *completely > remove the scaffold generator from the core of Rails* itself. This means > that there wouldn''t even be the option to run the scaffold generator for > newbies. You could then extract this out into a gem if you *really* wanted > people to have the option for it. However, if this path was taken it should > be made clear that this is not the "sanctioned" way to create controllers. > > Thoughts? > > -- > 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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Given only those two options, I would lean toward the first. I believe education is the answer here instead of all out removal. On Thursday, March 8, 2012 12:30:39 PM UTC-6, Ryan Bigg wrote:> > Hello friends, > > It''s been fun having the scaffold generator exist as a part of Rails since > The Beginning Of Time, but I think its time is now up. It has been abused > time and time again, and most often leads to confusion amongst people who > are new to Rails. > > This confusion happens when a user first generates a scaffold and sees > that it is good. They can perform CRUD actions on a resource using one > command?! WOW! > > Then they try to modify the scaffold and run into problems. First of all: > how do they add an action to the controller? Do they need to run another > command? How do they then define a route for that action? A template? > > If they were to *not* use the scaffold generator from the beginning, I > believe they would have less confusion. They would know how to add another > action to the controller and a template for that action because this would > be how they''re doing it from the start. Learning how to define a route for > a new action in the controller is something easily learnable by reading the > routing guide. > > I think that we can fix this problem in one of two ways, the latter more > extreme than the first one. > > The first way is that we *completely change the Getting Started Guide to > simply *mention* the scaffold generator*, but then show people the > "correct" way of generating a controller (rails g controller) and adding > actions to it one by one, adding a model as its needed, and using similar > practices to how you would do it in the "real world". > > The second way, and sorry if this sounds a little extreme, is to *completely > remove the scaffold generator from the core of Rails* itself. This means > that there wouldn''t even be the option to run the scaffold generator for > newbies. You could then extract this out into a gem if you *really* wanted > people to have the option for it. However, if this path was taken it should > be made clear that this is not the "sanctioned" way to create controllers. > > Thoughts? >-- 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/-/P7TvZoCGtkgJ. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Every time I use that generator, I always regret it. It''s just so easy, so tempting... That said, it''s something that Rails has had since the beginning of time, and was an original selling point. That said, you could _still_ do the fifteen minute blog video, you''d just run three commands instead of one. It would _also_ probably cause another internet shitstorm. I can see zillions of blog posts now. There''s no such thing as bad press... A big 4.0 release means a time to rethink old sacred cows. Changing the guide would help new people, but removing it entirely would be better. I like it. :) -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Thu, Mar 8, 2012 at 4:38 PM, Geoff Harcourt <geoff.harcourt@gmail.com> wrote:> I would be in favor of either of these two options. I imagine extracting and > gem-ifying the controllers would be a hassle, but then the default path for > setting up a new view and controller action would require the user to think > about what they are doing rather than just observe the magic. > > Unfortunately, I think that even if we were to extract out to a gem that > every non-official tutorial and book would just tell users to add > "rails_controller_generators" to their gemfile as the first step, and the > intended goal of this work would be completely bypassed.Pretty much this. Also, everyone using old books/tutorials (pre 4.0) will run into trouble. Don''t get me wrong, I''m wholly in favor of killing it. Repeatedly. And violently. But truth is, it''s hard do kill something that has been around this long, and that is included in pretty much all tutorials for rails that have existed since The Beginning of Time. Not sure what the best approach is. -foca> > On Thu, Mar 8, 2012 at 1:30 PM, Ryan Bigg <radarlistener@gmail.com> wrote: >> >> Hello friends, >> >> It''s been fun having the scaffold generator exist as a part of Rails since >> The Beginning Of Time, but I think its time is now up. It has been abused >> time and time again, and most often leads to confusion amongst people who >> are new to Rails. >> >> This confusion happens when a user first generates a scaffold and sees >> that it is good. They can perform CRUD actions on a resource using one >> command?! WOW! >> >> Then they try to modify the scaffold and run into problems. First of all: >> how do they add an action to the controller? Do they need to run another >> command? How do they then define a route for that action? A template? >> >> If they were to *not* use the scaffold generator from the beginning, I >> believe they would have less confusion. They would know how to add another >> action to the controller and a template for that action because this would >> be how they''re doing it from the start. Learning how to define a route for a >> new action in the controller is something easily learnable by reading the >> routing guide. >> >> I think that we can fix this problem in one of two ways, the latter more >> extreme than the first one. >> >> The first way is that we completely change the Getting Started Guide to >> simply *mention* the scaffold generator, but then show people the "correct" >> way of generating a controller (rails g controller) and adding actions to it >> one by one, adding a model as its needed, and using similar practices to how >> you would do it in the "real world". >> >> The second way, and sorry if this sounds a little extreme, is to >> completely remove the scaffold generator from the core of Rails itself. This >> means that there wouldn''t even be the option to run the scaffold generator >> for newbies. You could then extract this out into a gem if you *really* >> wanted people to have the option for it. However, if this path was taken it >> should be made clear that this is not the "sanctioned" way to create >> controllers. >> >> Thoughts? >> >> -- >> 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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Thursday, 8 March 2012 at 10:58 AM, Nicolás Sanguinetti wrote:> On Thu, Mar 8, 2012 at 4:38 PM, Geoff Harcourt <geoff.harcourt@gmail.com (mailto:geoff.harcourt@gmail.com)> wrote: > > I would be in favor of either of these two options. I imagine extracting and > > gem-ifying the controllers would be a hassle, but then the default path for > > setting up a new view and controller action would require the user to think > > about what they are doing rather than just observe the magic. > > > > Unfortunately, I think that even if we were to extract out to a gem that > > every non-official tutorial and book would just tell users to add > > "rails_controller_generators" to their gemfile as the first step, and the > > intended goal of this work would be completely bypassed. > > > > > Pretty much this. Also, everyone using old books/tutorials (pre 4.0) > will run into trouble. > > Don''t get me wrong, I''m wholly in favor of killing it. Repeatedly. And > violently. But truth is, it''s hard do kill something that has been > around this long, and that is included in pretty much all tutorials > for rails that have existed since The Beginning of Time. > > Not sure what the best approach is. > > -focaIn Rails 2 there was the removal of the scaffold method from the controllers. A major version then was the perfect time for that, and over time tutorials adjusted. If it was removed here, the same thing would occur.> > > > > On Thu, Mar 8, 2012 at 1:30 PM, Ryan Bigg <radarlistener@gmail.com (mailto:radarlistener@gmail.com)> wrote: > > > > > > Hello friends, > > > > > > It''s been fun having the scaffold generator exist as a part of Rails since > > > The Beginning Of Time, but I think its time is now up. It has been abused > > > time and time again, and most often leads to confusion amongst people who > > > are new to Rails. > > > > > > This confusion happens when a user first generates a scaffold and sees > > > that it is good. They can perform CRUD actions on a resource using one > > > command?! WOW! > > > > > > Then they try to modify the scaffold and run into problems. First of all: > > > how do they add an action to the controller? Do they need to run another > > > command? How do they then define a route for that action? A template? > > > > > > If they were to *not* use the scaffold generator from the beginning, I > > > believe they would have less confusion. They would know how to add another > > > action to the controller and a template for that action because this would > > > be how they''re doing it from the start. Learning how to define a route for a > > > new action in the controller is something easily learnable by reading the > > > routing guide. > > > > > > I think that we can fix this problem in one of two ways, the latter more > > > extreme than the first one. > > > > > > The first way is that we completely change the Getting Started Guide to > > > simply *mention* the scaffold generator, but then show people the "correct" > > > way of generating a controller (rails g controller) and adding actions to it > > > one by one, adding a model as its needed, and using similar practices to how > > > you would do it in the "real world". > > > > > > The second way, and sorry if this sounds a little extreme, is to > > > completely remove the scaffold generator from the core of Rails itself. This > > > means that there wouldn''t even be the option to run the scaffold generator > > > for newbies. You could then extract this out into a gem if you *really* > > > wanted people to have the option for it. However, if this path was taken it > > > should be made clear that this is not the "sanctioned" way to create > > > controllers. > > > > > > Thoughts? > > > > > > -- > > > 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 (mailto:rubyonrails-core@googlegroups.com). > > > To unsubscribe from this group, send email to > > > rubyonrails-core+unsubscribe@googlegroups.com (mailto:rubyonrails-core+unsubscribe@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 (mailto:rubyonrails-core@googlegroups.com). > > To unsubscribe from this group, send email to > > rubyonrails-core+unsubscribe@googlegroups.com (mailto:rubyonrails-core+unsubscribe@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 (mailto:rubyonrails-core@googlegroups.com). > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com (mailto:rubyonrails-core+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Anecdotally I can remember a few times I was glad, scaffolds existed like when teaching Rails classes to beginners, and having them excited to get started so quickly. I can also remember more than a few times I regretted using a scaffold after having to heavily remove or modify most of the code it generated. Rather than lean on either of these sets of experiences, is there some way we can test and validate that this would make using rails for beginners easier in the long run? Serious question. I''ll be happy to A/B test-teach this to a group of students if we could come up with some reliable way of measuring success. -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
IMO, the best value of scaffolds is writing custom ones for common tasks in your own application. I''ve done this on a number of occasions. It''s easy and I think it''s a quite under-utilized feature of rails. While basic CRUD is probably better delegated to engine''s now. the core concept in scaffolds seems to be that setting up an app quickly and taking the busy work out of building common things that need to be hand customized. Even an engine for admin UIs will have boilerplate. So why not combine these two approaches? TL;DR Don''t throw the baby out with the bathwater. Chris Eppstein On Thu, Mar 8, 2012 at 11:09 AM, richard schneeman < richard.schneeman@gmail.com> wrote:> Anecdotally I can remember a few times I was glad, scaffolds existed > like when teaching Rails classes to beginners, and having them excited > to get started so quickly. I can also remember more than a few times I > regretted using a scaffold after having to heavily remove or modify > most of the code it generated. Rather than lean on either of these > sets of experiences, is there some way we can test and validate that > this would make using rails for beginners easier in the long run? > Serious question. I''ll be happy to A/B test-teach this to a group of > students if we could come up with some reliable way of measuring > success. > > -- > 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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
I spent 4 years using Rails as a teaching language both inside and outside a local University. We stopped telling students that scaffolding even existed after two semesters. It wash''t that, as you might except, we had a problem with generating code instead of doing work by hand. Instead we saw that encountering scaffolding as an early Rails concept led many students to develop a totally bonkers mental model about the framework and web applications. Scaffolding set them up to fail. My general feeling after seeing it in action: A: You''re not doing a beginner any favors. This holds true for a number of other things that I''d love to see demonstrated long-form in the guides before the shortcuts are introduced. `resource`-style routes and form helpers are awesome time/LOC-savers when you know what they''re doing. When you don''t, they''re dark and mysterious magic words that you dare not examine too closely. When we teach student the Rails-style REST pattern conceptually, show them how to connect routes, controllers, and models themselves, then show them the handy time-savers provided by the framework they perform better and appreciate the niceties more. B: the advantages of Rails in 2012 aren''t the same as the advantages of Rails in 2005. In 2005 relatively few people writing web apps separated concerns into different types of objects, followed any particular organization pattern, wrote tests, or any of the the practices that made Rails seem like such a breath of fresh air. Now basically every app framework – regardless of language – follows these as best practices. Routing, MVC, tests, are all important to highlight but they''re par for the course. Scaffolding may have had some use in 2005 – it showed you how to properly write Rails before there was a body of well-written apps to examine – but there are better solutions to this problem now. The advantages in Rails today have to do with large, enthusiastic (although sometimes overly curt) developer community, the ecosystem of well written and tested Rails-compatible libraries, the collection of good instructional material both in the project itself (Guides) and from 3rd parties, and the fact that Rails is still one of the places were smart people are experimenting with different (hopefully better) ways of making applications. These are the things I''d miss if I was working with other tools and I think it''s what we should focus on highlighting and improving. - @trek On Thursday, March 8, 2012 at 1:39 PM, Steve Klabnik wrote:> Every time I use that generator, I always regret it. It''s just so > easy, so tempting... > > That said, it''s something that Rails has had since the beginning of > time, and was an original selling point. > > That said, you could _still_ do the fifteen minute blog video, you''d > just run three commands instead of one. > > It would _also_ probably cause another internet shitstorm. I can see > zillions of blog posts now. There''s no such thing as bad press... > > A big 4.0 release means a time to rethink old sacred cows. > > Changing the guide would help new people, but removing it entirely > would be better. > > I like it. :) > > -- > 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 (mailto:rubyonrails-core@googlegroups.com). > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com (mailto:rubyonrails-core+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
I don''t really get it. I''ve been using the scaffold for a while, never knew it wasn''t the sanctioned way of doing things. Many times all I need is a CRUD. The amount of customization I have to do is minimized by having project specific templates in lib/templates, and scaffold saves me quite some time. Even if I have to rewrite some or most of the generated code, I still think it''s pretty useful. I agree, thought, that you really shouldn''t use the scaffold if you''re a beginner and doesn''t know what''s going on. When I''m teaching Rails I use the scaffold for a 15-minute WOW factor, but then I jump straight to doing it piece by piece. Once one knows what the scaffold does, how you can customize it, and how you''d do it all without the scaffold, I don''t really see all the evilness in it. Can anyone please elaborate on the disadvantages of using the scaffold? :) On Thu, Mar 8, 2012 at 4:01 PM, Ryan Bigg <radarlistener@gmail.com> wrote:> On Thursday, 8 March 2012 at 10:58 AM, Nicolás Sanguinetti wrote: > > On Thu, Mar 8, 2012 at 4:38 PM, Geoff Harcourt <geoff.harcourt@gmail.com> > wrote: > > I would be in favor of either of these two options. I imagine extracting and > gem-ifying the controllers would be a hassle, but then the default path for > setting up a new view and controller action would require the user to think > about what they are doing rather than just observe the magic. > > Unfortunately, I think that even if we were to extract out to a gem that > every non-official tutorial and book would just tell users to add > "rails_controller_generators" to their gemfile as the first step, and the > intended goal of this work would be completely bypassed. > > > Pretty much this. Also, everyone using old books/tutorials (pre 4.0) > will run into trouble. > > Don''t get me wrong, I''m wholly in favor of killing it. Repeatedly. And > violently. But truth is, it''s hard do kill something that has been > around this long, and that is included in pretty much all tutorials > for rails that have existed since The Beginning of Time. > > Not sure what the best approach is. > > -foca > > In Rails 2 there was the removal of the scaffold method from the > controllers. A major version then was the perfect time for that, and over > time tutorials adjusted. If it was removed here, the same thing would occur. > > > > On Thu, Mar 8, 2012 at 1:30 PM, Ryan Bigg <radarlistener@gmail.com> wrote: > > > Hello friends, > > It''s been fun having the scaffold generator exist as a part of Rails since > The Beginning Of Time, but I think its time is now up. It has been abused > time and time again, and most often leads to confusion amongst people who > are new to Rails. > > This confusion happens when a user first generates a scaffold and sees > that it is good. They can perform CRUD actions on a resource using one > command?! WOW! > > Then they try to modify the scaffold and run into problems. First of all: > how do they add an action to the controller? Do they need to run another > command? How do they then define a route for that action? A template? > > If they were to *not* use the scaffold generator from the beginning, I > believe they would have less confusion. They would know how to add another > action to the controller and a template for that action because this would > be how they''re doing it from the start. Learning how to define a route for a > new action in the controller is something easily learnable by reading the > routing guide. > > I think that we can fix this problem in one of two ways, the latter more > extreme than the first one. > > The first way is that we completely change the Getting Started Guide to > simply *mention* the scaffold generator, but then show people the "correct" > way of generating a controller (rails g controller) and adding actions to it > one by one, adding a model as its needed, and using similar practices to how > you would do it in the "real world". > > The second way, and sorry if this sounds a little extreme, is to > completely remove the scaffold generator from the core of Rails itself. This > means that there wouldn''t even be the option to run the scaffold generator > for newbies. You could then extract this out into a gem if you *really* > wanted people to have the option for it. However, if this path was taken it > should be made clear that this is not the "sanctioned" way to create > controllers. > > Thoughts? > > -- > 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+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Friday, 9 March 2012 at 7:30 AM, Ryan Bigg wrote:> Hello friends, > > It''s been fun having the scaffold generator exist as a part of Rails since The Beginning Of Time, but I think its time is now up. It has been abused time and time again, and most often leads to confusion amongst people who are new to Rails. > > This confusion happens when a user first generates a scaffold and sees that it is good. They can perform CRUD actions on a resource using one command?! WOW! > > Then they try to modify the scaffold and run into problems. First of all: how do they add an action to the controller? Do they need to run another command? How do they then define a route for that action? A template? > > If they were to *not* use the scaffold generator from the beginning, I believe they would have less confusion. They would know how to add another action to the controller and a template for that action because this would be how they''re doing it from the start. Learning how to define a route for a new action in the controller is something easily learnable by reading the routing guide. > > I think that we can fix this problem in one of two ways, the latter more extreme than the first one. >The problem here is that none of us are the target audience for the scaffold generator, so we''re a terrible group to make decisions on its long-term utility. It isn''t, and never has been, intended as a way to create controllers which you just commit and ship, it''s a tool for giving an example controller and set of views which let''s a new user get a feel for how it all hangs together. Without something like this you start with a two line controller file and have *no* idea how anything works. Sure it''s great if everyone reads all the documentation and learns all the details of how actions and views interact before they write a single line of code, but the reality is people don''t do that.> > The first way is that we completely change the Getting Started Guide to simply *mention* the scaffold generator, but then show people the "correct" way of generating a controller (rails g controller) and adding actions to it one by one, adding a model as its needed, and using similar practices to how you would do it in the "real world". > >Changing the guides to use the scaffold generator only as an example seems like the best bet. Simply generate a controller, walk the user through how it works, show how to add an action and test, then never return to the scaffolding at all.> > The second way, and sorry if this sounds a little extreme, is to completely remove the scaffold generator from the core of Rails itself. This means that there wouldn''t even be the option to run the scaffold generator for newbies. You could then extract this out into a gem if you *really* wanted people to have the option for it. However, if this path was taken it should be made clear that this is not the "sanctioned" way to create controllers. >This is a step too far in my book, there''s valuable functionality here for newcomers and moving it to a plugin means it''s no longer available to them but *is* available to the rest of us. WTF would the point of that be ;)> > Thoughts? > > -- > 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 (mailto:rubyonrails-core@googlegroups.com). > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com (mailto:rubyonrails-core+unsubscribe@googlegroups.com). > For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.-- Cheers, Koz -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
I agree with pretty much everything everyone has said in terms of the scaffold
being a detriment in setting up the wrong mental model for newbies. It has also
been a long time since I''ve used the scaffold generators.
However, I try not to forget what my mindset was back then, before I knew what I
was doing. I remember really liking scaffolding back in the Rails 1 days when it
was a macro rather than a generator. And I also remember how much more I liked
it when it changed to being a generator, in terms of being less magical and more
logical.
Perhaps we can keep moving in the right direction without a dramatic change.
I''ll throw out a couple ideas that aren''t quite as dramatic as
what has been mentioned…
What if we kept the scaffolding generators, but changed the command to be more
explicit, making the user think about what''s happening? For example,
instead of just blindly setting up all the CRUD actions and routes, what if you
had to pass in the names of the methods you want and the REST methods they use?
E.g.
rails generate scaffold Article name:string title:string content:text
index:get show:get edit:get create:post update:put
Notice in the above, I don''t have any destroy action being created,
since I didn''t specify it. This could raise awareness of the controller
actions and routes that are being set up.
Then we could populate the controller actions with suggestions rather than
actual running code. So for example, the generated #create action could look
something like this:
# POST /article
# POST /article.xml
def create
# This is your #create action, accessed via a POST request to the /article
relative URL
# (which can be customized in config/routes.rb).
# Below is some boilerplate code you can uncomment to get going.
# Be sure to edit and customize the code as needed by your application.
#@article = Article.new(params[:article])
#
#respond_to do |format|
# if @article.save
# format.html { redirect_to(@article, :notice => ''Article was
successfully created.'') }
# format.xml { render :xml => @article, :status => :created,
:location => @article }
# else
# format.html { render :action => "new" }
# format.xml { render :xml => @article.errors, :status =>
:unprocessable_entity }
# end
#end
end
In the above example, I think just making people uncomment code for it to work
would make them give some thought to what they''re doing, and make it
clear that this code is just a suggestion to get started, which needs
customization.
-- Steve Schwartz
On Thursday, March 8, 2012 at 2:20 PM, Trek Glowacki wrote:
> I spent 4 years using Rails as a teaching language both inside and outside
a local University. We stopped telling students that scaffolding even existed
after two semesters. It wash''t that, as you might except, we had a
problem with generating code instead of doing work by hand. Instead we saw that
encountering scaffolding as an early Rails concept led many students to develop
a totally bonkers mental model about the framework and web applications.
Scaffolding set them up to fail.
>
> My general feeling after seeing it in action:
>
> A: You''re not doing a beginner any favors. This holds true for a
number of other things that I''d love to see demonstrated long-form in
the guides before the shortcuts are introduced. `resource`-style routes and form
helpers are awesome time/LOC-savers when you know what they''re doing.
When you don''t, they''re dark and mysterious magic words that
you dare not examine too closely.
>
> When we teach student the Rails-style REST pattern conceptually, show them
how to connect routes, controllers, and models themselves, then show them the
handy time-savers provided by the framework they perform better and appreciate
the niceties more.
>
>
> B: the advantages of Rails in 2012 aren''t the same as the
advantages of Rails in 2005. In 2005 relatively few people writing web apps
separated concerns into different types of objects, followed any particular
organization pattern, wrote tests, or any of the the practices that made Rails
seem like such a breath of fresh air. Now basically every app framework –
regardless of language – follows these as best practices. Routing, MVC, tests,
are all important to highlight but they''re par for the course.
Scaffolding may have had some use in 2005 – it showed you how to properly write
Rails before there was a body of well-written apps to examine – but there are
better solutions to this problem now.
>
> The advantages in Rails today have to do with large, enthusiastic (although
sometimes overly curt) developer community, the ecosystem of well written and
tested Rails-compatible libraries, the collection of good instructional material
both in the project itself (Guides) and from 3rd parties, and the fact that
Rails is still one of the places were smart people are experimenting with
different (hopefully better) ways of making applications.
>
> These are the things I''d miss if I was working with other tools
and I think it''s what we should focus on highlighting and improving.
>
> - @trek
>
> On Thursday, March 8, 2012 at 1:39 PM, Steve Klabnik wrote:
> > Every time I use that generator, I always regret it. It''s
just so
> > easy, so tempting...
> >
> > That said, it''s something that Rails has had since the
beginning of
> > time, and was an original selling point.
> >
> > That said, you could _still_ do the fifteen minute blog video,
you''d
> > just run three commands instead of one.
> >
> > It would _also_ probably cause another internet shitstorm. I can see
> > zillions of blog posts now. There''s no such thing as bad
press...
> >
> > A big 4.0 release means a time to rethink old sacred cows.
> >
> > Changing the guide would help new people, but removing it entirely
> > would be better.
> >
> > I like it. :)
> >
> > --
> > 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
(mailto:rubyonrails-core@googlegroups.com).
> > To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
(mailto:rubyonrails-core+unsubscribe@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
(mailto:rubyonrails-core@googlegroups.com).
> To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
(mailto:rubyonrails-core+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
On Thursday, 8 March 2012 at 11:30 AM, Elomar Souza wrote:> Can anyone please elaborate on the disadvantages of using the scaffold? :) > >This helpful Stack Overflow question should display why teaching noobs scaffold first off is a bad thing: http://stackoverflow.com/revisions/9622251/1. He''s shown way too much code, and if you take a look at his routes he has a whole bunch of actions that probably don''t need to be there. He has no idea what the controller provides to the view or how that even works. We should teach them this *first* (create a controller, actions, etc.) and then show them the shortcut to doing it (scaffold generator). Teaching them scaffold first is wrong. It''s a cheap trick that needs to die. I think that extracting it out into a gem and educating people on how Rails should be taught would have the best impact. The people who still want to use scaffolding for rapid prototyping can do that. -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> is there some way we can test and validate that > this would make using rails for beginners easier in the long run? > Serious question. I''ll be happy to A/B test-teach this to a group of > students if we could come up with some reliable way of measuring > success.Jumpstart Lab''s intro to Rails class teaches without scaffolding, and it''s really fantastic, actually. At the end, the big reveal of ''What you''ve done over the last day or two is just one command'' blows people''s minds, but we''ve had some of them say "I''m really glad you didn''t show us that first." -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> This helpful Stack Overflow question should display why teaching noobs scaffold first off is a bad thing: http://stackoverflow.com/revisions/9622251/1. He''s shown way too much code, and if you take a look at his routes he has a whole bunch of actions that probably don''t need to be there. He has no idea what the controller provides to the view or how that even works. >This guy has no idea what he''s doing, I don''t think that citing his case is at all useful. People can get confused no matter what you show them.> > We should teach them this *first* (create a controller, actions, etc.) and then show them the shortcut to doing it (scaffold generator). Teaching them scaffold first is wrong. It''s a cheap trick that needs to die. > >> I think that extracting it out into a gem and educating people on how Rails should be taught would have the best impact. The people who still want to use scaffolding for rapid prototyping can do that. >Once you know how the rest of it works, there''s no purpose to having the scaffold generator. You''re thinking about this thing completely backwards. After you know, using it is a cheap trick, before then it''s a useful way to get an example and dig in. -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Oh, I should have provided a link, as an example: http://tutorials.jumpstartlab.com/projects/jsblogger.html -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Thu, March 8, 2012 14:30, Elomar Souza wrote:> I don''t really get it. I''ve been using the scaffold for a > while, never knew it wasn''t the sanctioned way of doing > things.. . .> > Can anyone please elaborate on the disadvantages of using > the scaffold? :)There is really only one disadvantage to the scaffold generators: They have to be maintained. Every time Rails goes through one of its periodic syntax/structure paroxysms the generators are immediately placed out of date. A scaffold generator rewrite requires some detailed knowledge of the new ways of the Rails world otherwise the code they produce is worse than useless as exemplars. Unfortunately this knowledge is often limited in distribution around the time the changes are introduced. Further, those that do possess the requisite skills not infrequently have no wish to spend their limited time on something that they do not use themselves and perhaps believe is ''morally'' suspect from a professional point of view. I rather suspect that arguments about the benefits of building RoR apps ''from the ground up'' and potential confusion for Rails newcomers that might arise from using scaffolding is quite beside the point. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
I am not going into the discussion of how scaffold affect new comers but my personal experience is: I spend the first 15 minutes of each project customizing scaffold to do exactly what I want. I remove helpers generation, update the views to fit the layout, add responders and so on. Then I rely a lot on scaffold. I rely 10 times more when building the application''s backend (the admin section). So in this aspect, I wouldn''t like to see scaffold going anywhere. Besides, the scaffold generator and structure is fairly easy to maintain. -- 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/-/iirZVNNVTvMJ. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> > There is really only one disadvantage to the scaffold > generators: They have to be maintained.I think this is a great feature of the scaffold generator. Through the years, whenever there is a major release, I can "scaffold generate deleteme" and get a quick overview of some of the newness. No...it''s not as good as checking the source or guides, but it''s a very easy way to be introduced to what the current "way" is. Is that by itself enough to keep it around? I dunno...but I do like having them. Also, if maintaining the scaffold has been a problem, I''m willing to help...not that I presume to know all that''s required to do that right now, but I''m serious about the offer. (Just read José''s email and it may not actually be a problem.) On Thu, Mar 8, 2012 at 3:29 PM, James B. Byrne <byrnejb@harte-lyne.ca>wrote:> > On Thu, March 8, 2012 14:30, Elomar Souza wrote: > > I don''t really get it. I''ve been using the scaffold for a > > while, never knew it wasn''t the sanctioned way of doing > > things. > . . . > > > > Can anyone please elaborate on the disadvantages of using > > the scaffold? :) > > There is really only one disadvantage to the scaffold > generators: They have to be maintained. > > Every time Rails goes through one of its periodic > syntax/structure paroxysms the generators are immediately > placed out of date. A scaffold generator rewrite requires > some detailed knowledge of the new ways of the Rails world > otherwise the code they produce is worse than useless as > exemplars. > > Unfortunately this knowledge is often limited in > distribution around the time the changes are introduced. > Further, those that do possess the requisite skills not > infrequently have no wish to spend their limited time on > something that they do not use themselves and perhaps > believe is ''morally'' suspect from a professional point of > view. > > I rather suspect that arguments about the benefits of > building RoR apps ''from the ground up'' and potential > confusion for Rails newcomers that might arise from using > scaffolding is quite beside the point. > > > -- > *** E-Mail is NOT a SECURE channel *** > James B. Byrne mailto:ByrneJB@Harte-Lyne.ca > Harte & Lyne Limited http://www.harte-lyne.ca > 9 Brockley Drive vox: +1 905 561 1241 > Hamilton, Ontario fax: +1 905 561 0757 > Canada L8E 3C3 > > -- > 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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Well, I agree with those that think that Rails is not for beginners. Having said that, if we''re targeting beginners, you''ll get a framework that is beginners-friendly but may not be that nice for experienced users. And, in fact, I do think that scaffolds are actually more useful to experienced developers, specially if you have to often create lots of classes. It is so easy to override the default scaffold templates that every experienced developer could take advantage of the scaffold idea. The Model/Migration generators are specially useful for avoiding writing so much boilerplate code... So, I don''t really think we should be worried that much about beginners but write a framework that is useful for us. Cheers, Rodrigo. Em 08-03-2012 15:30, Ryan Bigg escreveu:> Hello friends, > > It''s been fun having the scaffold generator exist as a part of Rails > since The Beginning Of Time, but I think its time is now up. It has > been abused time and time again, and most often leads to confusion > amongst people who are new to Rails. > > This confusion happens when a user first generates a scaffold and sees > that it is good. They can perform CRUD actions on a resource using one > command?! WOW! > > Then they try to modify the scaffold and run into problems. First of > all: how do they add an action to the controller? Do they need to run > another command? How do they then define a route for that action? A > template? > > If they were to *not* use the scaffold generator from the beginning, I > believe they would have less confusion. They would know how to add > another action to the controller and a template for that action > because this would be how they''re doing it from the start. Learning > how to define a route for a new action in the controller is something > easily learnable by reading the routing guide. > > I think that we can fix this problem in one of two ways, the latter > more extreme than the first one. > > The first way is that we *completely change the Getting Started Guide > to simply *mention* the scaffold generator*, but then show people the > "correct" way of generating a controller (rails g controller) and > adding actions to it one by one, adding a model as its needed, and > using similar practices to how you would do it in the "real world". > > The second way, and sorry if this sounds a little extreme, is to > *completely remove the scaffold generator from the core of Rails* > itself. This means that there wouldn''t even be the option to run the > scaffold generator for newbies. You could then extract this out into a > gem if you *really* wanted people to have the option for it. However, > if this path was taken it should be made clear that this is not the > "sanctioned" way to create controllers. > > Thoughts? >-- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Agreeing with José, I work on a University, and we try to keep all our systems follow a pattern, so clients get used to our layout and design and our developers get standard comment tips about how to name and describe methods. For this, we rely strongly on scaffold customization. I also agree that this should not be put as an advantage for beginners on tutorials and books, showing them how to "not" write code. Even a warning message could appear on scaffolding generation, or making the generators a little less "automagic" (and maybe a little more dumb also), forcing people to customize scaffolds before getting something usable. I believe that with this aproach, we can change the maintenance cost of keeping the scaffold generators up to date from the core developers who would not need to firstly update generators, to the experienced developers who contribute to rails on every realease candidate. -- Att, Everton -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Mar 8, 2012, at 5:25 PM, Everton Moreth wrote:> Agreeing with José, I work on a University, and we try to keep all our systems follow a pattern, so clients get used to our layout and design and our developers get standard comment tips about how to name and describe methods. For this, we rely strongly on scaffold customization. > > I also agree that this should not be put as an advantage for beginners on tutorials and books, showing them how to "not" write code. Even a warning message could appear on scaffolding generation, or making the generators a little less "automagic" (and maybe a little more dumb also), forcing people to customize scaffolds before getting something usable.WAT. No, seriously - this is like a group of Ikea craftsmen deciding to no longer use pre-cut wood, since making customers cut it for themselves will teach them carpentry more quickly. "Dumbing down" the generator is them trying to split the difference by cutting to shape but not drilling holes; both approaches ignore that the "EAT UR VEGGIES NAOW" method only works if you''ve got customers that can''t choose an alternative. To me, it seems easier to imagine the counterfactual: imagine Rails *without* a similar generator, and then imagine the responses to a proposed generator that would automatically create reasonably clean, idiomatic code that a new developer could quickly see results from. Such a thing would likely be popular... --Matt Jones -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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+unsubscribe@googlegroups.com (mailto:rubyonrails-core+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
With gems like inherited_resource, I am not sure what the use of scaffolding is. On Thursday, March 8, 2012 1:30:39 PM UTC-5, Ryan Bigg wrote:> > Hello friends, > > It''s been fun having the scaffold generator exist as a part of Rails since > The Beginning Of Time, but I think its time is now up. It has been abused > time and time again, and most often leads to confusion amongst people who > are new to Rails. > > This confusion happens when a user first generates a scaffold and sees > that it is good. They can perform CRUD actions on a resource using one > command?! WOW! > > Then they try to modify the scaffold and run into problems. First of all: > how do they add an action to the controller? Do they need to run another > command? How do they then define a route for that action? A template? > > If they were to *not* use the scaffold generator from the beginning, I > believe they would have less confusion. They would know how to add another > action to the controller and a template for that action because this would > be how they''re doing it from the start. Learning how to define a route for > a new action in the controller is something easily learnable by reading the > routing guide. > > I think that we can fix this problem in one of two ways, the latter more > extreme than the first one. > > The first way is that we *completely change the Getting Started Guide to > simply *mention* the scaffold generator*, but then show people the > "correct" way of generating a controller (rails g controller) and adding > actions to it one by one, adding a model as its needed, and using similar > practices to how you would do it in the "real world". > > The second way, and sorry if this sounds a little extreme, is to *completely > remove the scaffold generator from the core of Rails* itself. This means > that there wouldn''t even be the option to run the scaffold generator for > newbies. You could then extract this out into a gem if you *really* wanted > people to have the option for it. However, if this path was taken it should > be made clear that this is not the "sanctioned" way to create controllers. > > Thoughts? >On Thursday, March 8, 2012 1:30:39 PM UTC-5, Ryan Bigg wrote:> > Hello friends, > > It''s been fun having the scaffold generator exist as a part of Rails since > The Beginning Of Time, but I think its time is now up. It has been abused > time and time again, and most often leads to confusion amongst people who > are new to Rails. > > This confusion happens when a user first generates a scaffold and sees > that it is good. They can perform CRUD actions on a resource using one > command?! WOW! > > Then they try to modify the scaffold and run into problems. First of all: > how do they add an action to the controller? Do they need to run another > command? How do they then define a route for that action? A template? > > If they were to *not* use the scaffold generator from the beginning, I > believe they would have less confusion. They would know how to add another > action to the controller and a template for that action because this would > be how they''re doing it from the start. Learning how to define a route for > a new action in the controller is something easily learnable by reading the > routing guide. > > I think that we can fix this problem in one of two ways, the latter more > extreme than the first one. > > The first way is that we *completely change the Getting Started Guide to > simply *mention* the scaffold generator*, but then show people the > "correct" way of generating a controller (rails g controller) and adding > actions to it one by one, adding a model as its needed, and using similar > practices to how you would do it in the "real world". > > The second way, and sorry if this sounds a little extreme, is to *completely > remove the scaffold generator from the core of Rails* itself. This means > that there wouldn''t even be the option to run the scaffold generator for > newbies. You could then extract this out into a gem if you *really* wanted > people to have the option for it. However, if this path was taken it should > be made clear that this is not the "sanctioned" way to create controllers. > > Thoughts? >-- 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/-/s7O105GGnjAJ. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On 9 Mar 2012, at 15:03, Ankur wrote:> With gems like inherited_resource, I am not sure what the use of scaffolding is.I think that what this discussion is missing out on is that many developers extend scaffolding (using the rails APIs, not monkey patching here), just like any other generator. The default out of the box might not be any good, but people who need to produce similar things either in a single project, or within many projects, would loose this basic and expected functionality. Yes we could add a gem which provides them, and then people extend them, but that would make some of the nicer automation rails has always provided a second class citizen.> On Thursday, March 8, 2012 1:30:39 PM UTC-5, Ryan Bigg wrote: > Hello friends, > > It''s been fun having the scaffold generator exist as a part of Rails since The Beginning Of Time, but I think its time is now up. It has been abused time and time again, and most often leads to confusion amongst people who are new to Rails. > > This confusion happens when a user first generates a scaffold and sees that it is good. They can perform CRUD actions on a resource using one command?! WOW! > > Then they try to modify the scaffold and run into problems. First of all: how do they add an action to the controller? Do they need to run another command? How do they then define a route for that action? A template? > > If they were to *not* use the scaffold generator from the beginning, I believe they would have less confusion. They would know how to add another action to the controller and a template for that action because this would be how they''re doing it from the start. Learning how to define a route for a new action in the controller is something easily learnable by reading the routing guide. > > I think that we can fix this problem in one of two ways, the latter more extreme than the first one. > > The first way is that we completely change the Getting Started Guide to simply *mention* the scaffold generator, but then show people the "correct" way of generating a controller (rails g controller) and adding actions to it one by one, adding a model as its needed, and using similar practices to how you would do it in the "real world". > > The second way, and sorry if this sounds a little extreme, is to completely remove the scaffold generator from the core of Rails itself. This means that there wouldn''t even be the option to run the scaffold generator for newbies. You could then extract this out into a gem if you *really* wanted people to have the option for it. However, if this path was taken it should be made clear that this is not the "sanctioned" way to create controllers. > > Thoughts? > > On Thursday, March 8, 2012 1:30:39 PM UTC-5, Ryan Bigg wrote: > Hello friends, > > It''s been fun having the scaffold generator exist as a part of Rails since The Beginning Of Time, but I think its time is now up. It has been abused time and time again, and most often leads to confusion amongst people who are new to Rails. > > This confusion happens when a user first generates a scaffold and sees that it is good. They can perform CRUD actions on a resource using one command?! WOW! > > Then they try to modify the scaffold and run into problems. First of all: how do they add an action to the controller? Do they need to run another command? How do they then define a route for that action? A template? > > If they were to *not* use the scaffold generator from the beginning, I believe they would have less confusion. They would know how to add another action to the controller and a template for that action because this would be how they''re doing it from the start. Learning how to define a route for a new action in the controller is something easily learnable by reading the routing guide. > > I think that we can fix this problem in one of two ways, the latter more extreme than the first one. > > The first way is that we completely change the Getting Started Guide to simply *mention* the scaffold generator, but then show people the "correct" way of generating a controller (rails g controller) and adding actions to it one by one, adding a model as its needed, and using similar practices to how you would do it in the "real world". > > The second way, and sorry if this sounds a little extreme, is to completely remove the scaffold generator from the core of Rails itself. This means that there wouldn''t even be the option to run the scaffold generator for newbies. You could then extract this out into a gem if you *really* wanted people to have the option for it. However, if this path was taken it should be made clear that this is not the "sanctioned" way to create controllers. > > Thoughts? > > -- > 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/-/s7O105GGnjAJ. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Mar 9, 2012, at 9:45 AM, Trek Glowacki wrote:> 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.Just my 2 cents. I think being overprotective of noobs from themselves is not exactly learning-friendly. Scaffolds may be bad when you''re actively mentoring someone, you get overwhelmed with having so much to explain at once, but for those who learn on their own (like I did) — scaffolds are something for me to discover, explore, abuse, ask a bunch of "how do I make scaffolding build my site for me" questions on IRC (there was no SO when I was learning), get yelled at, abandon them, then maybe rediscover them again as a configurable generator tool. That first "discover and explore" stage turned out invaluable as soon as I understood that scaffolds simply generated a bunch of code. From then on, I was reading the code and connecting the dots. Even at the point when I abandoned scaffolds, I still occasionally generated a Foo scaffold just to remember how it''s recommended to write create/update action in my controller, and such. Scaffolds are most useful to those who learn by example and learn alone. Did anyone speak out who isn''t teaching and isn''t being mentored? -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> With gems like inherited_resource, I am not sure what the use of scaffolding > is.Please note, from the inhereted_resources page: Since Rails 3 came out, I have no longer used Inherited Resources. I have found that the responders abstraction and custom Rails generators offer the perfect balance between hiding and showing too much logic. That said, I suggest developers to make use of the responders gem (at github.com/plataformatec/responders) and no longer use Inherited Resources. So even it is deprecated. ;) -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On 9 March 2012 17:46, Maxim Chernyak <madfancier@gmail.com> wrote:> On Mar 9, 2012, at 9:45 AM, Trek Glowacki wrote: > >> 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. > > Just my 2 cents. > > I think being overprotective of noobs from themselves is not exactly learning-friendly. Scaffolds may be bad when you''re actively mentoring someone, you get overwhelmed with having so much to explain at once, but for those who learn on their own (like I did) — scaffolds are something for me to discover, explore, abuse, ask a bunch of "how do I make scaffolding build my site for me" questions on IRC (there was no SO when I was learning), get yelled at, abandon them, then maybe rediscover them again as a configurable generator tool. > > That first "discover and explore" stage turned out invaluable as soon as I understood that scaffolds simply generated a bunch of code. From then on, I was reading the code and connecting the dots. Even at the point when I abandoned scaffolds, I still occasionally generated a Foo scaffold just to remember how it''s recommended to write create/update action in my controller, and such. > > Scaffolds are most useful to those who learn by example and learn alone. Did anyone speak out who isn''t teaching and isn''t being mentored?+1 on all that. Scaffolds are a boon to someone trying to work it out for themselves and they provide the instant gratification Wow factor that lets them get something up and running like magic. They did exactly that for me. Colin -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> Scaffolds are a boon to someone trying to work it out for themselves > and they provide the instant gratification Wow factor that lets them > get something up and running like magic. They did exactly that for > me.This doesn''t address the fact that scaffolds teach the learner incorrect things. Even if it''s instant, it''s still ultimately bad. Furthermore, since they shouldn''t use them when they get more advanced either, it leads them down the long path, and ''running like magic'' means that you didn''t really learn anything anyway. -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> Did anyone speak out who isn''t teaching and isn''t being mentored?I did not speak out, but learned rails on my own using training materials and attending some short classes. I started just before the end of the dynamic generators. I think everyone agrees that the dynamic generators were bad, but the current generators were a big help. They showed the correct way to build controllers and helped teach CRUD. It also provided a nice bookend to the routes resources macro. I hope we keep them, if we do chunk them we should also consider changing the default route generation for models to not use resources as that will create even more confusion. I like them, they helped me learn Rails and CRUD, I use them and I am stoked to learn I can customize them. On Mar 9, 2012, at 11:46 AM, Maxim Chernyak wrote:> On Mar 9, 2012, at 9:45 AM, Trek Glowacki wrote: > >> 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. > > Just my 2 cents. > > I think being overprotective of noobs from themselves is not exactly learning-friendly. Scaffolds may be bad when you''re actively mentoring someone, you get overwhelmed with having so much to explain at once, but for those who learn on their own (like I did) — scaffolds are something for me to discover, explore, abuse, ask a bunch of "how do I make scaffolding build my site for me" questions on IRC (there was no SO when I was learning), get yelled at, abandon them, then maybe rediscover them again as a configurable generator tool. > > That first "discover and explore" stage turned out invaluable as soon as I understood that scaffolds simply generated a bunch of code. From then on, I was reading the code and connecting the dots. Even at the point when I abandoned scaffolds, I still occasionally generated a Foo scaffold just to remember how it''s recommended to write create/update action in my controller, and such. > > Scaffolds are most useful to those who learn by example and learn alone. Did anyone speak out who isn''t teaching and isn''t being mentored? > > -- > 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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On 9 March 2012 18:06, Steve Klabnik <steve@steveklabnik.com> wrote:>> Scaffolds are a boon to someone trying to work it out for themselves >> and they provide the instant gratification Wow factor that lets them >> get something up and running like magic. They did exactly that for >> me. > > This doesn''t address the fact that scaffolds teach the learner > incorrect things.I don''t think it teaches them incorrect things, it fails to teach many things but what it does teach is ok. Can you give an example of an incorrect thing that it teaches?> Even if it''s instant, it''s still ultimately bad. > Furthermore, since they shouldn''t use them when they get more advanced > either, it leads them down the long path, and ''running like magic'' > means that you didn''t really learn anything anyway.I think I learned a lot from scaffolding when I was first trying to work out what rails was all about. Colin -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Fri, March 9, 2012 09:45, Trek Glowacki wrote:> 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.I agree that an incremental code generator for RoR would be an incredible tool. Whether it is feasible is another question. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Yes. Scaffolding is 99% of the time _not_ what you want. It encourages creating a 1-1 mapping between controllers and models, for one. It encourages creating all seven actions for every controller. It encourages generating a ton of code without tests. -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Friday, 9 March 2012 at 10:16 AM, Colin Law wrote:> On 9 March 2012 18:06, Steve Klabnik <steve@steveklabnik.com (mailto:steve@steveklabnik.com)> wrote: > > > Scaffolds are a boon to someone trying to work it out for themselves > > > and they provide the instant gratification Wow factor that lets them > > > get something up and running like magic. They did exactly that for > > > me. > > > > > > > > > This doesn''t address the fact that scaffolds teach the learner > > incorrect things. > > > > > I don''t think it teaches them incorrect things, it fails to teach many > things but what it does teach is ok. Can you give an example of an > incorrect thing that it teaches? > >The scaffold shows people one (and only one) way of developing a Rails application. You run this command, some magic happens and blammo! You''ve got a CRUD interface for a resource. I really think that newbies should be told scaffolding is useful for prototyping, but it''s not how people write real applications in the world. More thoughts in a moment...> > > Even if it''s instant, it''s still ultimately bad. > > Furthermore, since they shouldn''t use them when they get more advanced > > either, it leads them down the long path, and ''running like magic'' > > means that you didn''t really learn anything anyway. > > > > > I think I learned a lot from scaffolding when I was first trying to > work out what rails was all about. > > Colin > > -- > 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 (mailto:rubyonrails-core@googlegroups.com). > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com (mailto:rubyonrails-core+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Fri, Mar 9, 2012 at 7:06 PM, Steve Klabnik <steve@steveklabnik.com> wrote:>> Scaffolds are a boon to someone trying to work it out for themselves >> and they provide the instant gratification Wow factor that lets them >> get something up and running like magic. They did exactly that for >> me. > > This doesn''t address the fact that scaffolds teach the learner > incorrect things.Could we get technically specific on which "incorrect" things the scaffold brings? Maybe we could try to fix those specific issues (on a technical and documentation level). On a technical level, I see 3 specific (but fixable) problems: * the issue with attr_accessible is not explained (so the application is vulnerable to owner_of_record_id being set to another owner as in the recently publicized case). I see solutions for that (changing the code, in the direction suggested recently by @dhh (that is not attr_accessible, but a local function in the controller that slices the params in the controller context) and adding explanation about it). * the default auto-generated controller rspec tests have a few minor issues that make those tests brittle (comes down to slightly improving that format) * the views have a horrible amount of repetition. We should have a simple loop there doing each over an array of [:field_name, :type] entries (that structure is available anyway to produce the migration). That approach would also make it trivial to manually add and remove a few fields later on. Optimally that list of "active fields" in the new and edit views should be the slice list for filtering the incoming params in create and update actions (IMO that is the proper solution for the attr_accesible issue and it would be not too difficult to bake that right into the scaffold code). Besides these 3 issues, rails g scaffold continues to be valuable to me. E.g. I have actively used it this week to bootstrap a new project. The valuable points for me where: * migrations are made automatically * I get a an initial framework of rspec tests (model controller, views) that give a basic test scaffold as I start adapting the application to the real use case. * I had an immediate view on the actual data in existing production db. On a more general note, I would certainly want to continue to use scaffolds, in one form or another. HTH, Peter -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Replies inline. You may want to ensure you have supplies before reading this. It''s a bit long. On Friday, 9 March 2012 at 6:45 AM, Trek Glowacki wrote:> 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"That nicely sums it up. I think with C) it''s a great way to demonstrate what Rails can provide, but it should be demonstrated with a warning sign of "This is not how we do it normally!", or something along those lines. Regarding D), I''ve come to recognise that getting rid of scaffolding is probably not the way to go it, since José and Everton have both shown ways that non-noobs use it to a huge advantage, which I love the idea of.> > 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.Good idea. I worry though that the same people that would discuss it on GitHub would also discuss it here. GitHub *does* have a prettier interface though ;)> > 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 guidesI think that we could still keep it in the Getting Started Guide, just to demonstrate what Rails *can* provide you. After that quick win, we can get people into the mindset of creating what the scaffold created by running commands like "rails g controller" and "rails g model", while explaining everything along the route.> > 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 > >I like the idea of an interactive tutorial (tutorails? Thank you, thank you, here all day) Maybe some command that they can run like "rails_tutorial begin" that would generate an application that has a tutorial engine mounted... by way of the gem having a file at config/routes.rb that draws the routes on Rails.application.routes. Because if you had it inside the tutorial app''s routes, it may prompt the question "what is this line doing?" which is something for much further down the track. It would create the tutorial app and open their browser to http://localhost:3000/tutorial (or at least tell them what to do). The first page would explain exactly the beginning of Section 2 of Rails, as that''s a perfect introduction to what Rails is. I disagree that having MVC right up front as it is in the guide is a good idea. This should be introduced after a quick win. The next part of the tutorial gets the user to generate a posts scaffold and explains what functionality it provides: "allows you to create, read, update and delete posts. This is often referred to as CRUD". Encourage the user here to play around with the scaffold (give them objectives, like to create posts, edit one, delete one) and get them familiar to the flow of how it works. The third step destroys the scaffold, explaining that it''s not how things are done in the real world. Then we get the user to create a new posts controller, explaining here what controllers are. The "C" layer of MVC. Fourth: get the user to create a new action for the controller. Explain what actions are and how they work. Explain routing. Show the long form of "match ''posts/new'', :to => ''posts#new''" so that they understand routing from the beginning. The new action''s job is simply to provide a form to create a new post. For this, the user will need to create a model (and this is where you explain the "M" layer) and then a view (the "V" layer). That''s how you''ve got MVC explained. You''re walking them through each part of it as its needed, rather than explaining it immediately and up front. Fifth: The user makes a create action in the controller. Explain that forms that create data should use POST requests. Here would perhaps be a good place to explain REST. Add a flash notice to the create action, just like there is in the scaffold. Explain what this does. Sixth: Add a validation to the model. Show them that they can no longer save a post without a title. This would require editing of the controller action. Seven through to ???: Draw the rest of the fucking owl. (ref: http://s3-ec.buzzfed.com/static/imagebuzz/web03/2010/8/24/11/how-to-draw-an-owl-25123-1282662850-14.jpg) Point is: a tutorial that walks users through building a resource *from scratch* is so much more helpful than one that walks them through building one with scaffolding.> > - @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+unsubscribe@googlegroups.com (mailto:rubyonrails-core+unsubscribe@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 (mailto:rubyonrails-core@googlegroups.com). > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com (mailto:rubyonrails-core+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Quick question. Many posters have referred to creating their own custom scaffold generators instead of using the defaults. What is the most common way to do this? Custom gem? Engine in lib? Probably something else... I really like this solution. It is exactly what I need on many projects. A simple link to an article or even stackoverflow post would be awesome. Thanks -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Check out the generators guide. It contains info about how to modify the default generators. On 10/03/2012, at 5:20, pferdefleisch <pferdefleisch@gmail.com> wrote:> Quick question. > Many posters have referred to creating their own custom scaffold > generators instead of using the defaults. > What is the most common way to do this? > Custom gem? Engine in lib? Probably something else... I really like > this solution. It is exactly what I need on many projects. > A simple link to an article or even stackoverflow post would be > awesome. > Thanks > > -- > 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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
I think your first suggestion is the way to go. Scaffold does have the benetif of giving the new-comer a first shot of something "working", but as you rightly said, it tends to confuse a little. Paul On Thursday, March 8, 2012 7:30:39 PM UTC+1, Ryan Bigg wrote:> > Hello friends, > > It''s been fun having the scaffold generator exist as a part of Rails since > The Beginning Of Time, but I think its time is now up. It has been abused > time and time again, and most often leads to confusion amongst people who > are new to Rails. > > This confusion happens when a user first generates a scaffold and sees > that it is good. They can perform CRUD actions on a resource using one > command?! WOW! > > Then they try to modify the scaffold and run into problems. First of all: > how do they add an action to the controller? Do they need to run another > command? How do they then define a route for that action? A template? > > If they were to *not* use the scaffold generator from the beginning, I > believe they would have less confusion. They would know how to add another > action to the controller and a template for that action because this would > be how they''re doing it from the start. Learning how to define a route for > a new action in the controller is something easily learnable by reading the > routing guide. > > I think that we can fix this problem in one of two ways, the latter more > extreme than the first one. > > The first way is that we *completely change the Getting Started Guide to > simply *mention* the scaffold generator*, but then show people the > "correct" way of generating a controller (rails g controller) and adding > actions to it one by one, adding a model as its needed, and using similar > practices to how you would do it in the "real world". > > The second way, and sorry if this sounds a little extreme, is to *completely > remove the scaffold generator from the core of Rails* itself. This means > that there wouldn''t even be the option to run the scaffold generator for > newbies. You could then extract this out into a gem if you *really* wanted > people to have the option for it. However, if this path was taken it should > be made clear that this is not the "sanctioned" way to create controllers. > > Thoughts? >-- 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/-/3iI5BlDqVLgJ. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
I wasn''t referring about custom scaffold generators. I just said that it is pretty easy to customize the generators templates for your needs: http://guides.rubyonrails.org/generators.html#customizing-your-workflow-by-changing-generators-templates Best, Rodrigo. Em 10-03-2012 10:20, pferdefleisch escreveu:> Quick question. > Many posters have referred to creating their own custom scaffold > generators instead of using the defaults. > What is the most common way to do this? > Custom gem? Engine in lib? Probably something else... I really like > this solution. It is exactly what I need on many projects. > A simple link to an article or even stackoverflow post would be > awesome. > Thanks >-- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
I wasn''t sure where to jump into this thread, but my vote is to keep the generator since it is a helpful "canonical example" for those trying to get started. However, I do suggest one change, that might sound a bit radical, but which I think supports most of the thinking I''m seeing in this thread: rename the generator to something that makes it clear it''s more for educational purposes than anything else. Something like "example_resource" might make it really, really obvious that the code is an example, shows all the possible actions, even has a couple of responders, etc... basically a way to see a good example of both code and forms that follow all of the naming conventions. But it''s clear it''s just an *example* and not simply a real starting point. $ rails g example_resource Product title sku Of course, it *is* a real starting point for those of us who understand Rails and use it like Jose does - we know how to customize what we want - but for those new to Rails it''s clear it''s just an example to help them understand the possibilities and get familiar with the conventions. I think also getting the name "resource" in there helps normalize our vocabulary a bit more instead of "scaffold" which isn''t really used anywhere else in the framework. Jeff -- 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/-/NglvoM95wiIJ. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
I''m in agreement here. Renaming to prefix with example_ would solve two issues. First, it would explicitly show it to be an example and having to type that would reinforce that. Second, by also adding a statement to the very top of each generated file via some header addition would also help reinforce that. A statement that this is just to give them an idea should suffice. On Mar 21, 12:12 am, Jeff Cohen <cohen.j...@gmail.com> wrote:> I wasn''t sure where to jump into this thread, but my vote is to keep the > generator since it is a helpful "canonical example" for those trying to get > started. > > However, I do suggest one change, that might sound a bit radical, but which > I think supports most of the thinking I''m seeing in this thread: rename the > generator to something that makes it clear it''s more for educational > purposes than anything else. > > Something like "example_resource" might make it really, really obvious that > the code is an example, shows all the possible actions, even has a couple > of responders, etc... basically a way to see a good example of both code > and forms that follow all of the naming conventions. But it''s clear it''s > just an *example* and not simply a real starting point. > > $ rails g example_resource Product title sku > > Of course, it *is* a real starting point for those of us who understand > Rails and use it like Jose does - we know how to customize what we want - > but for those new to Rails it''s clear it''s just an example to help them > understand the possibilities and get familiar with the conventions. > > I think also getting the name "resource" in there helps normalize our > vocabulary a bit more instead of "scaffold" which isn''t really used > anywhere else in the framework. > > Jeff-- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.