At RailsConf Europe 2008, I spent some time playing with my own
implementation of ActiveModel. Most of the validations stuff has been
implemented now, so I think it's ready to be shared with the
community.
I have not yet tried to integrate this into ActiveRecord (yet). Doing
so is probably quite a lot of work (deprecations etc.), and if it's
done now, it probably has to be re-done by the time of deciding to
actually implement it in the master branch (be it my implementation or
someone elses).
Some notes:
* After talking to DHH on the mentioned RailsConf and showing him my
ActiveModel implementation at the state it was in at that time, he
suggested having a system to hook your own validation methods in a way
that made sure they were available to all libraries using
ActiveModel::Validations. I have implemented this with the
ActiveModel::Validations.add method.
* It does not use the L18n library for validation messages, for no
particular reason. It doesn't really matter at this point, I guess,
and as far as I know, all it takes is adding a .t to the strings.
* The validations sort of implement it's own callback system as of
now. It should probably rely on ActiveModel::Callbacks instead.
Regarding the callback library in ActiveModel. I just started working
on that as a stand-alone implementation of callback functionality. But
I guess using ActiveSupport::Callbacks makes sense here?
Decided to remove ActiveModel::Callbacks alltogether. What exactly
should it do, anyway? For the purpose of making validations work, I'd
say it's overkill. Perhaps there's something I haven't though of.
This is kind of interesting to me b/c way back I suggested to DHH that
the underlying DB adapter code would also be a good thing to extract
into a separate project (I dubbed it ActiveDBA, I think DHH suggested
calling it ActionAdapter). I never ended up doing it, but still think
it would be a good project --and actually rather trivial by comparison
to what you are working on, I imagine. Perhaps there is interest
enough now that someone would like to pursue it? Although I wonder,
what is left of ActiveRecord once ActionAdapter and ActiveModel are
separated out of it?
In any case, bringing it all together I think these smaller project
units are a good idea and make an excellent stack of technologies in
its own right.
In places where performance is critical, or when dealing with legacy
databases, it might be necessary to drop to raw SQL. An
"ActionAdapter" might make that a bit easier.
I've pinged david again to get his feedback. From my own perspective,
we're so close to shipping 2.2 that I'm tryiing not to get distracted
by shiny new things
I like the fact that you're cleaning up validations, we've had a few
other threads on this recently, and in the 2.3 lifecycle it'd be
really nice integrate a nice, modular validations module.
So yeah, I like the approach you've taken, but would prefer to hold
off doing anything with it for a few weeks while we try and get a 2.2
beta out the door.
Didn't we talk about tweaking some of the state machine event guarding
and state transitioning stuff to use more validations and callbacks
too? Being able to add validations to anything would be interesting.
The toy yak shave project I thought I was going to be working on over
the summer didn't pan out (no couchdb for me). Therefore, I didn't
get anything done on AMo liked I probably said I would
Didn't we talk about tweaking some of the state machine event guarding
and state transitioning stuff to use more validations and callbacks
too? Being able to add validations to anything would be interesting.
I recently experimented with state machines that use callbacks/
observers. I also detect transitions that occur through direct state
manipulation (as opposed to invoking an event! method... e.g.
update_attributes(:state => 'closed')) and fire the appropriate enter/
exit callbacks.
