views:

57

answers:

1

I was trying to debug why <%= @user.address1 %> wasn't showing up in the view. The associated column was setup as a string, as in:

t.string   "address1"
t.string   "address2"
t.string   "city"
t.string   "state"
t.string   "zip"
t.string   "phone"

When I debugged the model using debug(@user), I got:

address1: 123 Main St.
city: Santa Barbara
address2: ""
zip: "93101"
state: CA

Associated view for inputting info into the db:

 <tr>
  <td width="300">Address: </td>
  <td><%= u.text_field :address1 %><br></td>
 </tr>
 <tr>
  <td width="300">Address2: </td>
  <td><%= u.text_field :address2 %><br></td>
 </tr>
 <tr>
  <td>City:</td>
  <td><%= u.text_field :city %></td>
 </tr>
 <tr>
  <td>State:</td>
  <td><%= u.text_field :state %></td>
 </tr>
 <tr>
  <td>Zip Code:</td>
  <td><%= u.text_field :zip %></td>
 </tr>
 <tr>
  <td>Phone:</td>
  <td><%= u.text_field :phone %></td>
 </tr>

I fixed the problem by using <%= @user.address1.to_s %> but from the debug output along with the schema I thought the column was already a string. I did notice that while the zip code contained quotations around it designating a string, the address1 did not.

So why couldn't I initially use <% [email protected] %> without converting it to string? What kind of variable is the 123 main st. without quotations?

+1  A: 

The debug helper only uses quotes when they're necessary to show a value is a string. It puts quotes around the zip so you know it's not a number, and "" for address2 so you know it's not nil. The rest are clearly strings. I don't love this behavior, but this is how it works.

So, since your @user.address1 was already a string, why wasn't it appearing until you added to_s? I'm not sure. From what I can see it looks like it should. Could you maybe post some code from the view that displays it? What if you try <%=h @user.address1 %>? If you view the HTML source of the page, is anything there?

Alex Reisner
It works now. I have no idea what happened, but I had restarted the server multiple times and recreated the DB. Hmm. Thanks for the info that debug only puts "" around fields that need clarification... that's kinda hokey, I wish it just did it around every variable.
Kevin