How do you use Observers?

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…

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?

Daniel W. wrote:

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

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 W. [email protected]

[email protected] 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.

Thanks for the reply!

Daniel W. wrote:

end
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:

http://dev.rubyonrails.org/ticket/7968

Wincent C. wrote:

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…