Created
August 2, 2012 20:56
-
-
Save excid3/3240587 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
<td><%= link_to transferred_from(call), call %></td> | |
<td><%= link_to transferred_to(call), call %></td> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 | |
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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