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.
On Nov 7, 5:50 pm, linojon
<lino...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:> 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
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---