-
-
Save excid3/3240587 to your computer and use it in GitHub Desktop.
<td><%= link_to transferred_from(call), call %></td> | |
<td><%= link_to transferred_to(call), call %></td> |
def transferred_from(call) | |
if call.transferred_from? | |
call.transferred_from.facility_name | |
else | |
call.transfer_from_other | |
end | |
end | |
def transferred_to(call) | |
if call.transferred_to? | |
call.transferred_to.facility_name | |
else | |
call.transfer_to_other | |
end | |
end | |
if call.transferred_from? within the helper is named the same as the attribute in the association transferred_from. Could that have something to do with it? The other string is not nil, it has a value you when you view the record.
The way I was doing it outside of a helper was if call.transfer_from_other == nil call.transferred_from.try(:facility_name) else call.transfer_from_other and it works, but it's super-ugly.
Well the logic is, if there is an facility that's associated, you want to display that. So that's where the if is coming from. If that always returns true for some weird reason, then that might be the problem.
Try switching it. I was trying to clean the logic up by using those methods instead but they could have broken things. Also == nil is bad, try transfer_from_other.nil? instead
Swapped the logic around and it worked. Here's the code:
def transferred_from(call)
if call.transferred_from.nil?
call.transfer_from_other
else
call.transferred_from.try(:facility_name)
end
end
Good call on == nil. Learned something new today :)
Cool. Yeah so normally you don't want to do this because you want to take the "happy path". Checking for nils is bad because that's the sad path first. Once you get more complex logic, that concept will begin to make a bit more sense.
Just check the logic, make sure it's not backwards, etc.