For example, now that Observer methods are effectively being rolled into the
normal callback chain of the models they observe, what exactly is their
point? Wouldn't it now be just as effective, and arguably easier to grok, to
simply put peripheral callbacks in a module and include them directly in the
I'm not so sure that it's actually easier to understand. There's
definitely something nice about having a single class which has a
particular aspect of object lifecycle. That class can be tested and
refined in isolation and can be turned on and off independently of the
model in question. In my own code I typically use model callbacks for
the bulk of the callback behaviour, observers are typically only for
truly tangential things like cache expiry.
Also, doesn't this new refactoring mean that observer callbacks can now halt
the execution chain where they couldn't before?
Good question, if they can I'm not sure that it would be the end of the world.
Finally, using after_commit in the observer is not quite the same thing as
the previous behaviour as you can't distinguish between after_commit on
create and update without doing it in the model directly, right?
after_commit fires on destroy too, so it's even slightly more
confusing. There's after_commit :your_thing, :on=>:create for model
level callbacks, but I don't believe that's available if you're using
observers. There probably should be.
I can't say I feel particularly strongly either way, just interested in
stimulating some debate on what are some subtle but still potentially
significant behavioural changes. At the very least, the docs/guides should
probably be updated to document the new behaviour.
I definitely agree here, the change isn't particularly earth
shattering or confusing, so long as it's well documented with a few
examples. The current callbacks documentation is actually quite good,
but perhaps could do with some refinement.