# Where to trigger email notifications?

**URL:** <https://www.ruby-forum.com/t/where-to-trigger-email-notifications/119561>\
**Category:** Rails\
**Created:** [November 7, 2007, 11:51pm UTC](https://www.ruby-forum.com/t/where-to-trigger-email-notifications/119561 "2007-11-07T23:51:31Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![linojon](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/b3f665/32.png) [@linojon](https://www.ruby-forum.com/u/linojon)\
**Post date:** [November 7, 2007, 11:51pm UTC](https://www.ruby-forum.com/t/where-to-trigger-email-notifications/119561/1 "2007-11-07T23:51:31Z")

</div>

Hi,

isnt it round-about that restful-authentication’s registration stuff  
uses observers to send out notification emails?  
I mean, it sets variables like recently\_activated and  
recently\_forgot\_password to signal the emails should be sent,  
and then an observer looks if one of those has been set.  
But these variables are set in only one place, so it’s not really  
DRYing anything.  
Seems extra complicated to me.  
Wouldn’t be more straightfoward to just deliver the email directly  
from the model than set and observe those temporary state variables?

In fact, I’m thinking of stripping them out of the model and moving  
it up into the controller, so that, for example, admin actions can  
have the option of generating those emails rather than always being  
send without control.

What’s your strategy for email notifications of events in your  
application? do you use observers? do you do it in model vs controller?

–linoj

---

<div class="post-metadata">

**Author:** ![linojon](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/b3f665/32.png) [@linojon](https://www.ruby-forum.com/u/linojon)\
**Post date:** [November 8, 2007, 6:03am UTC](https://www.ruby-forum.com/t/where-to-trigger-email-notifications/119561/2 "2007-11-08T06:03:12Z")

</div>

one possible reason: separation of concerns. the model might need to  
be able to say whether it’s been recently\_activated or not, but  
doesn’t care outside of that. the observer contains your business  
logic for such state changes… if it finds a recently\_activated  
model, it can tell a mailer to do something.

the controller’s not the best place IMHO since it’s primary concern is  
modifying the database and selecting a view.