On Mar 4, 2006, at 19:52, David Heinemeier Hansson wrote:
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 |
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
