Clarification: I'm asking how YOU use them, not how TO use them.
I ask because after reading a post over at Pivotal Blabs (a very good blog, btw), it appears the Observer isn't quite meant to do what I thought it was. Example:
class UserObserver
def before_validation(user) user.errors.add_to_base("Can't delete.") if user.admin? end
end
I would expect the above to halt the saving of the object because it now fails validation. But it doesn't. The record gets saved anyway.
Then I tried...
class UserObserver
def before_validation(user) user.admin? end
end
Perhaps returning false would halt the process. Not so. In fact, the only way to stop a save inside an observer is to raise an exception:
class UserObserver
def before_validation(user) raise StandardError if user.admin? end
end
But I don't want to raise an exception. It's not an exceptional situation -- the model simply failed validation.
Meanwhile, I've recently discovered you can do this...
I've seen the validate method before, but I didn't know you could stack it like that. Anywho, if you add errors to the object inside any of these methods, validation fails, which is fine.
But I'm left with wondering... what's the purpose of an Observer outside of sending e-mails and logging messages?
I'm relatively new to rail, and have only done minimal work with observers, but I've seen them used for caching purposes. To remove cached versions of pages after a model has been updated/saved, and things of that nature. I've never considered using them for model validation, as you point out that work belongs in the validation area of the model, not in an observer.
On Oct 19, 4:51 pm, Daniel Waite <rails-mailing-l...@andreas-s.net> wrote:
wen...@gmail.com wrote: > I'm relatively new to rail, and have only done minimal work with > observers, but I've seen them used for caching purposes. To remove > cached versions of pages after a model has been updated/saved, and > things of that nature.
Interesting. I've never dealt with page caching, but that sounds like a good candidate for observers.
> I've never considered using them for model validation, as > you point out that work belongs in the validation area of > the model, not in an observer.
And I guess I'm realizing that the observer isn't the place for validation. Looking back it seems silly. The observer's role is to react based on what it observes, not interfere with the models actions.
Daniel Waite wrote: > Clarification: I'm asking how YOU use them, not how TO use them.
> I ask because after reading a post over at Pivotal Blabs (a very good > blog, btw), it appears the Observer isn't quite meant to do what I > thought it was. Example:
> class UserObserver
> def before_validation(user) > user.errors.add_to_base("Can't delete.") if user.admin? > end
> end
> I would expect the above to halt the saving of the object because it now > fails validation. But it doesn't. The record gets saved anyway.
> Then I tried...
> class UserObserver
> def before_validation(user) > user.admin? > end
> end
> Perhaps returning false would halt the process. Not so. In fact, the > only way to stop a save inside an observer is to raise an exception:
I ran into exactly the same problem when I first began experimenting with observers:
Interesting activity. I wonder what will come of it. It bothered me more when I expected the observer to be able to halt the process of a save. Now that I no longer have that expectation it doesn't bother me so much.
I dunno what the exact role of an observer should be, so I can't really comment on it. Unless, of course, I defined my own role... But that's up to the core team. Though I'm sure a cunning Rubyist could achieve any desired effect via a plugin.
|
