metaquestion and scaffolding
bsco...@gmail.com
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?
Jeremy Evans
<bsco...@gmail.com> wrote:
>
> 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
Jan De Poorter
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
Michael Koziarski
>
> 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".
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.
--
Cheers
Koz
Michael Koziarski
>
> 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
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.
--
Cheers
Koz