validates_inclusion_of on boolean within file fails

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 Doe
  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 Doe
  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.

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 Jones

Matt Jones 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 Jones

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.

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 Doe
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]

Would it work if you used :in ["true","false"]? I have not tried it.

Colin

Colin Law wrote:

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.