Scaffold Generator Woes

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.

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

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

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

With gems like inherited_resource, I am not sure what the use of scaffolding is.

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.

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?

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

+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

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.

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.

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

I agree that an incremental code generator for RoR would
be an incredible tool. Whether it is feasible is another
question.

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.

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…

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

Replies inline. You may want to ensure you have supplies before reading this. It’s a bit long.

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

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

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

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

Check out the generators guide. It contains info about how to modify the default generators.

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