Scaffold Generator Woes

rubyonrails-core
1

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?

2

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.

3

Given only those two options, I would lean toward the first.

I believe education is the answer here instead of all out removal.

4

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. :slight_smile:

5

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

6

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.

7

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.

8

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

9

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:    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

10

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? :slight_smile:

11

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 :wink:

12

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])

13

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.

14

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

15

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.

16

Oh, I should have provided a link, as an example: http://tutorials.jumpstartlab.com/projects/jsblogger.html

17

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? :slight_smile:

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.

18

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.

19

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

20

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.