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? --~--~---------~--~----~------------~-------~--~----~ 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, Feb 15, 2008 at 4:38 AM, bscofield@gmail.com <bscofield@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 --~--~---------~--~----~------------~-------~--~----~ 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 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 On 15 Feb 2008, at 21:41, Jeremy Evans wrote:> > On Fri, Feb 15, 2008 at 4:38 AM, bscofield@gmail.com > <bscofield@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 > > >--~--~---------~--~----~------------~-------~--~----~ 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 Feb 16, 2008 10:06 AM, Jan De Poorter <jan@openminds.be> wrote:> > 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 --~--~---------~--~----~------------~-------~--~----~ 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 Feb 16, 2008 1:38 AM, bscofield@gmail.com <bscofield@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). > > 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. -- 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 -~----------~----~----~----~------~----~------~--~---