Hi paving, Thanks very much for your response to my complaint about lack of Rails support for handling changes.
Bottom line: I think you've shown that the approach I wished Rail's offered is, in fact, at hand. I'll try it today!! > What you keep talking about wanting to do is impractical for an > automatic procedure. I accept your assessment about impracticality of automated updating of scaffolding in the general case. However, I'm focused on apps in early stages of development after scaffolding and migration. After making changes to a table in the database, complementary changes in the Rails implementation are limited to four files in app\views. They have a straight-forward pattern that are susceptible to analysis by one or two regexp's per views That lets me present an abstract layout that I can modify and supplement with new code. That can be feed to a generator for each of the views. > delete the existing view files and generate the scaffolding again. Wow! I thought of trashing the current state of the whole thing, but rejected it because it was too tedious and boring. As I said, I'll try it today!! Best wishes and thanks, Richard On May 17, 4:01 am, pavling <[email protected]> wrote: > On 17 May 2010 03:30, RichardOnRails > > <[email protected]> wrote: > > > <snip conceited ramblings> > > > I feel like writing a generator to populate views when > > columns are added/renamed/dropped from a DB table. It annoys my that > > there's no tool to do that. > > What you keep talking about wanting to do is impractical for an > automatic procedure. > Consider your position: > You've run a generator that has created a bunch of boilerplate code > for you, which you've then fiddled with; edited to remove and > rearrange the fields - Rails doesn't know what you've done. > Then you migrate to add a new column. > > Where in the view would "Rails" put that if it were to update your > views for you? How will the generator look in your view for a > iteration through the records, or "know" what variable name you have > assigned to your object? (it would be pretentious, and dangerous, of > the framework to assume you've left it as the default) > > Personally, I'd get grumpy if the framework started messing with my > views after they'd been created. > > If you want the framework to do it for you; when you add your new > column, delete the existing view files and generate the scaffolding > again. That way the generator will know (because there's no existing > files) that it needs to create the boilerplate for you, and will have > all of the fields, including your new field, included. > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Talk" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group > athttp://groups.google.com/group/rubyonrails-talk?hl=en. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
