-
-
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 | |
I was going to do something similar in a helper. Just wanted to see if the logic made sense.
Many thanks!
Yeah, this is the kind of stuff that Gary goes over in DAS that I really love. It's great stuff.
I tried to implement it however transferred_from is already an attribute used in the association in Call.rb so I renamed it to transfer_from. Get an undefined method on transfer_from when I call call.transfer_from(call) within the helper. A trace talks about activemodel/record saying "method missing". Any ideas? I see where you are going with the confident code but I think somethings amiss.
These method names aren't attached to an object so you don't have to rename them.
Gotcha. I switched it back and when it displays the call facility it displays as: #Facility:0x007ff927b71740 when it displays other it displays as /calls/36 or whatever the call is. Almost as if it's trying to display nil. Thoughts?
Yeah sounds like the first isn't calling facility_name and the second is an empty string or nil returned.
Just check the logic, make sure it's not backwards, etc.
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.
@teknull I think this is what you were wanting. Confident code in the view. You just want to show something.
The helper can decide what to show.