I\'m a newb at programming but in my application I want certain cases to display \"yes\" or \"no\" instead of \"true\" or \"false\". I\'m not sure the best way to do this,
I recommend using Rails locales. These enable you to define language text for any of your variables. For example, your app can say "Yes"/"No" for English speakers, and "Oui"/"Non" for French speakers.
Locales are also fast, flexible, and easy to change because they are independent of your typical source code. You can see how locales will lead to very good separation between your source code logic versus the text that you render.
Example:
#./config/locales/en.yml
en:
TrueClass: "Yes"
FalseClass: "No"
#./app/views/items/index.html.erb
The value is <%= translate(myboolean.class) %>
The translate method can be abbreviated like this <%= t myboolean.class %>
You will likely see other people coding it like this using a helper:
#./app/helpers/application.rb
def yesno(x)
x ? "Yes" : "No"
end
# ./app/views/items/index.html.erb
<%= yesno(myboolean) %>
Or like this using a constant:
#./app/helpers/application.rb
YESNO = {true: "Yes", false: "No"}
# ./app/views/items/index.html.erb
<%= YESNO[myboolean] %>
These are both quick-and-dirty PHP-like solutions. There are better ways to do it.
You asked about this question: Rails (or Ruby): Yes/No instead of True/False.
# ./app/lib/extensions/true_class.rb
class TrueClass
def yesno
"Yes"
end
end
# ./app/views/items/index.html.erb
<%= myboolean.yesno %>
This is called "monkey patching" a Ruby class. In general it's not a good idea for doing what you're trying to do. Why not? Because it breaks an existing Ruby class to force that method into all of your code. This may be OK in rare cases (IMHO) but definitely not for monkey patching view text into a logic class (again IMHO).
You have the right general idea about creating your own migration data type, yet it may be overkill for your case because a boolean is such a typical one-to-one match for a yes/no. When would you want to create your own type? For example if you wanted to store the yes/no using different database primitive types, such as a using a bit flag in one database vs. a string enum in another database.
A decorator is a general concept for any app. In Rails, a decorator is a way to add view logic to an existing model or class.
The Rails locales are essentially decorators.
For more advanced needs, there's a good decorator gem called "Draper" which is easy to use. Using decorators tends to help view code be well organized, well namespaced, and easier to test.