I didn't really want to "come out" with this just yet - although I'm
95% certain this is the general architecture I want to go with, I'm
only about 60% or so done with the implementation, and only 40% or so
done with the testing.
I also haven't actually started running backwards compatibility tests,
mostly because I hadn't really settled on what I would be deprecating
(and of course some stuff just plain isn't done yet so I'd get lots of
failures about crap I already know doesn't work).
I have added comments (that look like # RUY-NOTE) at the top of most
source-files to indicate what is mostly done, and what is still in
progress, and what is marked for death. I have also added detailed
overviews for the main classes - but I will be pasting most of them in
this post for your reading pleasure.
Regardless, I mentioned my work in passing on #rails-contrib today and
it turns out technoweenie has been working on more or less the same
thing, but since we've both been publishing-shy we totally missed each
other and now there is overlap. Go go "release early" I guess
Anyway, so here we are - I'm "releasing" it - but do keep in mind this
is pre-alpha. Implementation is NOT complete.
I'm looking for feedback (and of course patches! but my expectations
are low), specifically about:
1. Are the public-facing API changes too extreme? (Validations
themselves are mostly the same, Errors is quite different however, but
IMO, well worth it)
2. Does the current "design" (architecture? whatever) make it easier
to implement some neat validation feature you've been burning to add?
I tried to pick up as many ideas as I could from "the wild" and pretty
much everything I saw should be very very easy to add (if I haven't
added them already).
Some examples include: internationalizable default error messages, JS
validations generated from model the model class, reporting errors via
JSON, per-state or per-transition validations with state machine,
Validatable's :group option.
3. What color should the bike-shed be?
Ok so what exactly is this anyway?
Well, it's my take on ActiveModel::Validations, which will hopefully
replace ActiveRecord::Validations one day soon, and of course it will
also form the basis for ActiveResource::Validations and could in
theory be used for any number of things (like presenter models,
couchdb models, whatever).
The most obvious changes it the rename to Validatable (mostly because
i wanted to save Validations for the modules containing the validation
- fairly different .errors API
- error messages themselves encapsulated in ErrorMessage class
2. Validations are now classes
Also note that because this module MUST be able to stand alone (for
use in presenters etc), it does not COMPLETELY supplant
ActiveRecord::Validations. AR-specific stuff like
the :on=>:save|:update|:create option, as well as
validates_uniqueness_of are taken care of by AR:V, albeit by extending
I will go over the new validations class first because it's less
contentious and generally speaking more awesome.