Hi,
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:
<%= f.label :purpose %><br />
<%= f.text_field :purpose %>
Of course the name “purpose” appears, among other places, also in
app\views\expenses\index.html.erb
Purpose |
[snip]
<% @expenses.each do |expense| %>
<%=h expense.purpose %> |
In short, can I make changes like this:
- simply through the “change” mechanism of migration -or-
- with a Ruby program to make case-sensitive changes in all files
with names ending in .rb or .html -or
- some other way aside from manually?
Thanks in advance,
Richard
Of course the name “purpose” appears, among other places, also in
<%=h expense.purpose %> |
In short, can I make changes like this:
- simply through the “change” mechanism of migration -or-
- with a Ruby program to make case-sensitive changes in all files
with names ending in .rb or .html -or
- 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…
perl -i -p -e ‘s/:purpose /:description /g’ file1 file2 file3
perl -i -p -e ‘s/.purpose /.description /g’ …
perl -i -p -e ‘s/>Purpose</>Description</g’ …
etc…
That right there might get most of them.
-philip
Hi,
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.
Regards,
Richard
On May 13, 4:18 pm, RichardOnRails
Hey Phil,
One more question: I should only make changes in .rb and .erb files
subordinate to the app directory, right?
Thanks again,
Richard
Hi Philip,
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
Best wishes,
Richard
Hi,
Thanks for you feedback.
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
Best wishes,
Richard
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.
Eric