This is required because the JSON gem is incompatible with Rails behavior and was not allowing ActiveModel::Errors to be serialized.
So we need to ensure Rails implementation is the one triggered. [#4890 state:resolved]
This makes it possible to pass additional options through Validators to message generation. E.g. plugin authors want to add validates_presence_of :foo, :format => "some format".
Also, cleanup the :default vs :message options confusion in ActiveModel validation message generation.
Also, deprecate ActiveModel::Errors#add_on_blank(attributes, custom_message) in favor of ActiveModel::Errors#add_on_blank(attributes, options).
Also, refactoring of ActiveModel and ActiveRecord Validation tests. Test are a lot more DRY now. Better test coverage as well now.
The first four points were reapplied from an older patch of Sven Fuchs which didn't apply cleanly anymore and was not complete yet.
Signed-off-by: José Valim <jose.valim@gmail.com>
Having a huge array to whitelist options is not the proper way to handle this case. This means that the ActiveModel::Errors object should know about the options given in *all* validators and break the extensibility added by the validators itself. If the intent is to whitelist options before sending them to I18n, each validator should clean its respective options instead of throwing the responsibility to the Errors object.
This reverts commit bc1c8d58ec.
This makes it possible to pass additional options through Validators to message
generation. E.g. plugin authors want to add validates_presence_of :foo, :format
=> "some format".
Also, cleanup the :default vs :message options confusion in ActiveModel
validation message generation.
Also, deprecate ActiveModel::Errors#add_on_blank(attributes, custom_message) in
favor of ActiveModel::Errors#add_on_blank(attributes, options).
Original patch by Sven Fuchs, some minor changes and has been changed to be applicable to master again
[#4057 state:committed]
Signed-off-by: Jeremy Kemper <jeremy@bitsweat.net>
Obviously #key is a too common name to be included
in the AMo interface, #to_key fits better and also
relates nicely to #to_param. Thx wycats, koz and
josevalim for the suggestion.
AR's #to_key implementation now takes customized
primary keys into account and there's a testcase
for that too.
The #to_param AMo lint makes no assumptions on how
the method behaves in the presence of composite
primary keys. It leaves the decision wether to
provide a default, or to raise and thus signal to
the user that implementing this method will need
his special attention, up to the implementers. All
AMo cares about is that #to_param is implemented
and returns nil in case of a new_record?.
The default CompliantObject used in lint_test
provides a naive default implementation that just
joins all key attributes with '-'.
The #to_key default implementation in lint_test's
CompliantObject now returns [id] instead of [1].
This was previously causing the (wrong) tests I
added for AR's #to_key implementation to pass. The
#to_key tests added with this patch should be
better.
The CI failure was caused by my lack of knowledge
about the test:isolated task. The tests for the
record_identifier code in action_controller are
using fake non AR models and I forgot to stub the
#to_key method over there. This issue didn't come
up when running the test task, only test:isolated
revealed it. This patch fixes that.
All tests pass isolated or not, well, apart from
one previously unpended test in action_controller
that is unrelated to my patch.
