metaquestion and scaffolding

rubyonrails-core
1

So here's a question - I want to start (or restart?) a discussion on the role of scaffolding. Should I do that here, or in Talk? I'm inclined to say here, since it would (hopefully) have a noticeable impact on core... and given that, I'll go ahead and say my piece (and just repost it to Talk if that's the consensus).

As it currently stands, scaffolding is broken. We all know it's not production-ready code (unlike, say, Django's), and it doesn't really educate new users in the best practices of Rails development (it uses for loops, has insufficient testing, etc.) I think these two distinct goals have made life more difficult for loads of people - from new Rails devs picking up less-than-optimal habits, to contributors who keep submitting patches to make scaffolding more solid (and to the people who +1 or reject those patches).

My proposal, then, is to separate these goals. Refocus scaffolding on providing solid, usable code, and accept patches that move it closer to that. Instead of just abandoning the educational aspects, however, split them out and address them in a downloadable sample application that is designed to teach best practices - something like the caboose sample app (though that hasn't been updated since May, I think). I think this will go a long way towards meeting both goals - scaffolding will be more useful, and new developers will have a focused sample application to learn from.

Comments?

2

So here's a question - I want to start (or restart?) a discussion on the role of scaffolding. Should I do that here, or in Talk? I'm inclined to say here, since it would (hopefully) have a noticeable impact on core... and given that, I'll go ahead and say my piece (and just repost it to Talk if that's the consensus).

I'm not sure how much core is interested in scaffolding. From what I've read, they don't use it.

As it currently stands, scaffolding is broken. We all know it's not production-ready code (unlike, say, Django's), and it doesn't really educate new users in the best practices of Rails development (it uses for loops, has insufficient testing, etc.) I think these two distinct goals have made life more difficult for loads of people - from new Rails devs picking up less-than-optimal habits, to contributors who keep submitting patches to make scaffolding more solid (and to the people who +1 or reject those patches).

I think the idea is that if you want good scaffolding, you use a plugin such as Scaffolding Extensions, ActiveScaffold, or Streamlined. Better default scaffolding has been brought up numerous times and it has been shot down every time.

My proposal, then, is to separate these goals. Refocus scaffolding on providing solid, usable code, and accept patches that move it closer to that. Instead of just abandoning the educational aspects, however, split them out and address them in a downloadable sample application that is designed to teach best practices - something like the caboose sample app (though that hasn't been updated since May, I think). I think this will go a long way towards meeting both goals - scaffolding will be more useful, and new developers will have a focused sample application to learn from.

I expect the reaction from core to be "that sounds like a great idea for a plugin".

Jeremy

3

I have a (maybe old) view on scaffolding. I personally never use it,
because it has bad code and I can do it better and faster myself.
People who come to rails, on the other hand, have an immediate close
encounter with scaffolding. They start using it, and start editing in
the code. At the end of the day those 2 "encounters" with scaffolding
should be the same: have nice, workable code, which also shows "the
rails way".

Don't abandon scaffolding, or leave it be, because I think using
scaffolding could be a very good starting point for both new Rails
users as experienced Rails programmers.

And if the default answer is "Use a good plugin", why is the
scaffolding code still in Rails. I'd say either improve it or get rid
of it completely.

Just my two cents. Jan De Poorter

4

This use is exactly what I think scaffolding is for. Rather than generating your application's administration interface, you get some sample code which you can use to learn the ropes. so any improvements to scaffolding should be targeted around helping people *learn* rather than helping people get a magical admin interface. Streamlined and co do a great job at that.

This focus on learning is why we removed the scaffold :posts stuff.

5

So here's a question - I want to start (or restart?) a discussion on the role of scaffolding. Should I do that here, or in Talk? I'm inclined to say here, since it would (hopefully) have a noticeable impact on core... and given that, I'll go ahead and say my piece (and just repost it to Talk if that's the consensus).

As it currently stands, scaffolding is broken. We all know it's not production-ready code (unlike, say, Django's), and it doesn't really educate new users in the best practices of Rails development (it uses for loops, has insufficient testing, etc.).

Education is the goal with scaffolding, not production ready code. For your specific complaints: We've had discussions on the merits of for loops and .each before, but I think it's an awful stretch to say it's a 'bad practise'. It's basically impossible to generate decent tests given a single table name and the attributes.

Having said that, any patches which people think will help people learn will be greatfully received. I'm willing to admit that I'm hardly scaffold's target audience, so if you can think of anything which will help out new users, I'd be glad to talk about that.

\> My proposal, then, is to separate these goals. Refocus scaffolding on

providing solid, usable code, and accept patches that move it closer to that. Instead of just abandoning the educational aspects, however, split them out and address them in a downloadable sample application that is designed to teach best practices - something like the caboose sample app (though that hasn't been updated since May, I think). I think this will go a long way towards meeting both goals - scaffolding will be more useful, and new developers will have a focused sample application to learn from.

The nice thing about learning from scaffolds is that you're learning from *your* domain, so you don't have to spend the whole time mentally transforming relationships and code from 'blog' to 'insurance policies'. The biggest downside of sample apps is what you've already mentioned, they're bloody hard to keep updated. It's a sample application, who has the motivation to keep it current?

I think perhaps there's another option, enhance scaffolding so it's as good an introduction as it can be. Then provide sample applications for people to learn more detailed best practises.