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.
The simplest option to get setup is to create a helper method which you can put in the application helper.
# in app/helpers/application_helper.rb
def boolean_to_words(value)
value ? "Yes" : "No"
end
This is analogous to many other Rails conversion helpers such as number_to_currency
Assuming you have :boolean
attribute in your model/database, you can do this:
class Foo < ActiveRecord::Base
def bar
self[:bar] ? 'Yes' : 'No'
end
end
The whenever you want the "Yes"/"No" value, call @foo.bar
. Whenever you want the true
/false
value, call @foo.bar?
or @foo[:bar]
.