I've got an app close to ready as version 1, but client wants labels
on a form and corresponding column names in the database changed, e.g.
the label/column named "purpose" to "description".
I've got a form defined in app\views\expenses\new.html.erb with a
field defined as:
Of course the name "purpose" appears, among other places, also in
app\views\expenses\index.html.erb
<table>
<tr>
<th>Purpose</th>
[snip]
</tr>
<% @expenses.each do |expense| %>
<tr>
<td><%=h expense.purpose %></td>
In short, can I make changes like this:
1. simply through the "change" mechanism of migration -or-
2. with a Ruby program to make case-sensitive changes in all files
with names ending in .rb or .html -or
3. some other way aside from manually?
I've got an app close to ready as version 1, but client wants labels
on a form and corresponding column names in the database changed, e.g.
the label/column named "purpose" to "description".
I've got a form defined in app\views\expenses\new.html.erb with a
field defined as:
Of course the name "purpose" appears, among other places, also in
app\views\expenses\index.html.erb
<table>
<tr>
<th>Purpose</th>
[snip]
</tr>
<% @expenses.each do |expense| %>
<tr>
<td><%=h expense.purpose %></td>
In short, can I make changes like this:
1. simply through the "change" mechanism of migration -or-
2. with a Ruby program to make case-sensitive changes in all files
with names ending in .rb or .html -or
3. some other way aside from manually?
You could also just leave the database column and change the visible labels. That works if the field really is the 'purpose', but can get confusing down the road to remember to label it as 'Description'.
If you're going to change it, change the column using a migration.
And *manually* change all the occurrences of it. "grep -ri purpose *" will find all the instances of it. You don't want to do it programmatically because you might very well end up changing the sentence "the purpose of the description is to" to "the description of the description is to" which isn't what you want.
Of course, if you see reasonable patterns in the output of grep by all means do some magic on them... for example maybe...
Maybe the best way is just to recreate the app using the new names and
then re-implement the enhancements I added to reach the current
version. I'm going to start that approach while I wait for some
advice about a better way.
Thanks for your fast and thoughtful response. I had posted that I was
going to embark on a fresh implementation, but now I'm encouraged to
try the migration+grep approach.
But I'll use Ruby to apply the grep. Using perl feel like now gone
20th century
One more question: I should only make changes in .rb and .erb files
subordinate to the app directory, right?
You should also be changing the files in your test directories.
If it were me, I would change just the tests first, verify that
everything related to the model/forms is breaking, and then make the
fixes to the code.
My custom search.rb and transform.rb programs did the job, I think. No
test programs were implicated because I'm delinquent on employing
formal testing on my first real Rails app. I know its sinful, but I
survived a career of computer consulting without formal testing, so
I'll do so for at least the initial stages of one more application
