> It has come to my attention the above wall of text is a little
> intimidating and is holding back adoption ;)
Quite ;)
> So I present to you a summary, in ADD-friendly, fixed-with 68-char
> column formatted (to appease google's crazy ML reader) point form:
>
> - I re-wrote ActiveModel::Validations -> renamed to
> ActiveMoldel::Validatable
> - Inspired by the Validatable gem (sort of)
> - Would like to replace ActiveRecord::Validation with it
Rick's the guy to talk with about this stuff, he's been more vocal
about about changing active record's validations to be based on active
model's.
> - @person.errors[:name] is a no-no. [] is used for index access
> just like a normal array. e.g. @person.errors[2..4] etc
I definitely don't like the maybe-return-an-array thing, but
errors[:foo] is fine. I don't quite follow why you haven't made it an
alias for on or something similar. errors[2] seems more yagni, who
wants to have error number 3?
Alternatively, the [] method can just do different things if it's
passed a symbol or an int / range.
> - You can FILTER errors for a specific attribute using
> errors.on()
> - e.g. @person.errors.on(:name)
> - or maybe @person.errors.on(:company)
> - includes errors from associated Company object
> - the returned array is still an Errors instance
> - so you can do
> @person.errors.on(:company).on(:business_number)
nice
> - Error messages themselves encapsulated in ErrorMessage class
> - each error message knows who it belongs to
> - handy for certain kinds of AJAX tricks
> - easier to work with in general
> - @person.errors.add("msg") converts strings to ErrorMessages
> automatically
> - @person.errors.on(:name).add("msg") will do the right thing
> for configuring the ErrorMessage object
> - lots of edge cases -> see bigger writeup above
>
> - ErrorMessages have far more powerful templating facilities then
> the printf based system from before.
> - e.g. "{attribute_name} '{value}' must not exceed {max}
> {units}."
> - shows up as "User name 'fofofofofoffofofo' must not exceed
> 10 characters."
> - More helpful default error messages, no longer constrained in
> word-order.
> - Pretty much required for i18n-able default error messages.
>
> That's the gist of it!
Nice work.
If I can make a process related comment though, it would have been
cool to bounce some of these ideas around here first before dropping
such a large patch. You could have got a few people to help out and
got feed back on the API before you had code and tests that'd need
changing.
--
Cheers
Koz
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---
