[slightly off-topic] FWIW, I've been telling my experienced developers learning Rails to avoid scaffolding. They are un-agile IMO in the sense that they encourage deviation from proper story-driven development and test-first programming. Perhaps just me, and certainly a subtle psychological thing, but it wasn't until I stopped using scaffolding that I bothered to really dive deep into the functional testing features of Rails.
Cheers, Obie On 3/4/06, Dave Thomas <[EMAIL PROTECTED]> wrote: > > > On Mar 4, 2006, at 19:52, David Heinemeier Hansson wrote: > > > > > > I agree that it's kinda nice, though. I just don't think its worth the > > pain. Where the pain being that 1) you can't run scaffold before > > setting up database (and it dies mid-air if you do), 2) the flow is > > backwards for migrations, 3) the form doesn't update if you add > > additional columns, and 4) the code to make this work is convoluted. > > > I see that, and (FWIW) I agree. Except... > > From the point of someone who trains newcomers to Rails, the fact that the > scaffolding generates a form means that they can see what a form looks like. > When they have to add a column, they can cut and paste a 2 lines from the > existing form to make the new field work. If there's no form code there, > there's nothing to copy. > > So, there's a kind of breakpoint: during the rock-and-roll phase of > development, I recommend folks use dynamic scaffolds, so they can > concentrate of checking their model contains the fields it needs. Then, at > some point, I suggest they generate a static scaffold. At that point, if > they add stuff to the schema, they'll need to edit _form.rhtml. But, at this > point, they don't mind this, because they're also interested in changing the > look of the forms. To be honest, they normally don't get into the controller > code at all. > > The other changes at this point will be adding validations and behaviors to > the models. (This can be problematic, as it breaks the unit tests, but > that's a good excuse to explain that tests must be kept up to date.) > > So, what I'm thinking is that, based on my experience with with training > side, there's not must point in static scaffolding with no _form.rhtml. > Without that feature, we may as well just use dynamic scaffolding. > > So, is that significant? I think it is. Earlier, I remember folks saying > that experienced Rails developers don't often use scaffolding. So, if > scaffolding is a feature aimed at folks just starting out, then perhaps we > need to give these folks what they need out of the feature. > > I don't think there's a clear good answer here. In the absence of something > that's obviously a lot better, I'd suggest we hold off making changes until > we have that blinding flash of inspiration. Lets drop the migration creation > from 'generate scaffold'. > > > Dave > > > > > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core > > > > _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
