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.
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.
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.
Perhaps, perhaps…
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.