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.