
Auto_Validations should be handled in the order specified
Reported by Brian Rose | March 2nd, 2008 @ 10:32 PM
The current method of handling auto_validations! is specified via a hash, which causes out-of-order problems (i.e. specifying ':nullable => false, :format => :email_address' and validations happening backward). To fix this, we can introduce an array instead of a hash (see patch). While it isn't ideal, it works more reliably.
It's worth noting that hashes are ordered in Ruby 1.9, and this change can be rolled back once 1.9 is considered de facto.
Comments and changes to this ticket
-
Sam Smoot March 15th, 2008 @ 06:42 PM
- State changed from new to open
I think a better solution to this issue might involve introducing the concept of validator precedence. Just like + takes higher precedence than /, we can make some assumptions about validations such as a validates_presence_of takes precedence over anything else.
Poke holes please. ;-)
I do think the internal mechanisms should account for declared order, it's the inlines I'm not so sure about since they're more than just validators. They can also be field definitions/constraints.
-
Dan Kubb (dkubb) April 15th, 2008 @ 03:34 AM
- Milestone cleared.
-
Sam Smoot May 21st, 2008 @ 01:26 AM
- Assigned user set to Adam French
Adam,
A feature for you to implement! :-)
Validation precedence as auto-validations are concerned.
Just to clarify: Standard validations should preserve the order in which they are defined. Auto-validations should provide a precedence to give the Hash options some more meaning.
So the change here is that we need to map/select something like:
[:nullable, :length, :format].each do |type| if options.has_key?(type) case type when :nullable then validates_is_present(name) when :length then validates_length(name, option[:length]) else raise 'CAN BE AWESOMES!' end end end
You get the point. Precedence for auto-validations only.
-
Sam Smoot June 2nd, 2008 @ 04:56 PM
- Milestone cleared.
-
Adam French July 20th, 2008 @ 05:46 PM
- Assigned user cleared.
- Tag set to dm-more, patch, property
-
Dan Kubb (dkubb) December 12th, 2008 @ 03:25 PM
- Tag changed from dm-more, patch, property to dm-more, property
- State changed from open to resolved
This patch does not cleanly apply to dm-core.
It looks like dm-validations has been updated so that auto-validation proceeds in a predefined manner, and validations are executed in the order they are defined in.
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »