

DHH: Think of emails as views delivered through SMTP - rufo
http://www.loudthinking.com/posts/43-think-of-emails-as-views-delivered-through-smtp

======
bradgessler
Doesn't this all just depend on specific needs? At Poll Everywhere we have an
email that gets fired off if a poll is close to filling-up. If we put this
logic in controllers it would be madness considering that we accept votes via
SMS, Web, etc. Instead we fire off the notification as a callback on our Poll
model after a vote is received.

On the other hand, when a user signs up at PE, we fire that email off via the
controller. There are certain times in our application where we don't want to
send an email out simply when a new User model is created.

This seems like a silly argument; just do what works best for your app. Is an
email a view? Use it in your controller. Is your email an asynchronous
notification? Maybe it belongs in your model.

~~~
bodhi
I think the problem of where to put them stems from having applications as an
MVC 'stack', as jrockway said in a sibling thread. Assuming that there is only
one input/output point in a web-app is not very realistic. It seems that these
applications might fit better in a hexagonal architecture[1], but Rails
doesn't really support apps like that, so you have to cram mailers in where
you can.

[1] <http://c2.com/cgi/wiki?HexagonalArchitecture>

~~~
bradgessler
I can attest to that. We walked down the "One MVC" stack idea which simply
doesn't work if an application has various modalities like Email, SMS, and
Twitter. It turns out Rails view/controller stack is awesome for web
applications, but _only_ web applications.

For different modalities, like Email, SMS, or Twitter interactions, do NOT
attempt to hack it into rails; rather, reuse the models defined in a Rails
project and implement or use a different view/controller stack better suited
for those environments.

------
wgj
The post is a direct response to:

[http://www.robbyonrails.com/articles/2009/11/16/sending-
emai...](http://www.robbyonrails.com/articles/2009/11/16/sending-email-
controllers-versus-models)

Discussed here:

<http://news.ycombinator.com/item?id=944686>

------
some1else
That was always the way I thought about emails in Ruby on Rails.. Multipart
itself makes you focus on the "template" aspect of an email. When you're done
with it, there's rarely a need to have any complicated business logic
associated with the action, other than triggering or queueing the delivery.

------
jrockway
The real take-away here is how poorly suited MVC is to web applications.

