How do you use Observers?
Daniel Waite
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...
class User
validate :there_can_be_only_one_admin
validate :another_validation
validate :yet_another
end
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?
So, how do you use Observers in your projects?
--
Posted via http://www.ruby-forum.com/.
Daniel Waite
> class UserObserver
>
> def before_validation(user)
> user.admin?
> end
>
> end
Sorry, that should read:
class UserObserver
def before_validation(user)
return false if user.admin?
true
end
end
wen...@gmail.com
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:
Daniel Waite
> 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.
Thanks for the reply!
Wincent Colaiuta
> 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:
Daniel Waite
> I ran into exactly the same problem when I first began experimenting
> with observers:
>
> http://dev.rubyonrails.org/ticket/7968
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...