Well I’m making a lot of headway with reading an uploaded yml file that
contains values that are read and then inserted into the model. The
formatted .yml file now looks like this:
theme:
name: My Theme
author: John D.
date: 2010-01-01
stylesheets: true
javascripts: false
layouts: true
swfs: true
I’m reading all of these yml values through a file upload which stores
it into a hash.
When saving the values to my database, all of the validators work
perfectly with the exception of the boolean reads.
validates_inclusion_of :stylesheets, :javascripts, :layouts, :swfs, :in
=> [true, false]
If it contains true it does not fail and stores the value as true.
If it contains false it does not fail and stores the value as false.
If it contains nothing it fails and says that it must contain a boolean
value.
All good right?
If it contains anything “booga, dodo, ugha, etc.” it stores it as
“false” and does not fail. This is my problem.
theme:
name: failure
author: John D.
date: 2010-01-01
stylesheets: true
javascripts: booga
layouts: true
swfs: true
This will validate fine and store the javascripts as a boolean for
false. Why does this validation not work with this?
Thanks.
On Jan 12, 7:19Â pm, Alpha B. [email protected] wrote:
If it contains true it does not fail and stores the value as true.
If it contains false it does not fail and stores the value as false.
If it contains nothing it fails and says that it must contain a boolean
value.
All good right?
If it contains anything “booga, dodo, ugha, etc.” it stores it as
“false” and does not fail. Â This is my problem.
It’s likely you’re having an issue with the AR typecasting code; the
relevant bit is from schema_definitions.rb:
def value_to_boolean(value)
if value.is_a?(String) && value.blank?
nil
else
TRUE_VALUES.include?(value)
end
end
Essentially, anything that isn’t blank and isn’t “true-y” (see the
list in the source) gets mapped to false.
About the only way I can think of to avoid this is to override the
accessors for those variables and map everything that isn’t true to
nil.
–Matt J.
Matt J. wrote:
Essentially, anything that isn’t blank and isn’t “true-y” (see the
list in the source) gets mapped to false.
About the only way I can think of to avoid this is to override the
accessors for those variables and map everything that isn’t true to
nil.
–Matt J.
Thanks Matt,
In the relative scheme of things it works in the way it should. If
someone places a boolean value of true it is indeed true. If someone
places a boolean value of false it is indeed false. If someone leaves
it empty, it will validate incorrectly and the message will be
displayed. So, overall, it’s working fine.
If, however, someone places some strange value that is not true or false
it also returns false. I’m fine with that as it is highly unlikely that
someone would do such a thing and if they do, it returns the expected
behavior, only it does not send them the message.
2010/1/13 Alpha B. [email protected]:
 layouts: true
 swfs: true
I’m reading all of these yml values through a file upload which stores
it into a hash.
When saving the values to my database, all of the validators work
perfectly with the exception of the boolean reads.
validates_inclusion_of :stylesheets, :javascripts, :layouts, :swfs, :in
=> [true, false]
Would it work if you used :in [“true”,“false”]? I have not tried it.
Colin
Colin L. wrote:
2010/1/13 Alpha B. [email protected]:
 layouts: true
 swfs: true
I’m reading all of these yml values through a file upload which stores
it into a hash.
When saving the values to my database, all of the validators work
perfectly with the exception of the boolean reads.
validates_inclusion_of :stylesheets, :javascripts, :layouts, :swfs, :in
=> [true, false]
Would it work if you used :in [“true”,“false”]? I have not tried it.
Colin
Yeah, I had tried that and also tried using %w with the same values,
both of which caused all 4 validations on the boolean fields within the
yaml file to fail. It probably would work if I put my yaml file to use
something similar:
stylesheets: “true”
javascripts: “false”
etc.
It probably requires the implicit string reasoning for those values.
I’m going to keep it the way I have it right now though.
Thanks for the follow-up Colin, it’s always appreciated.