pharrington wrote: > On Aug 7, 11:54�pm, Phlip <phlip2...@gmail.com> wrote: >> Views should be dumb, Controllers thin, and Models fat. >> >> If the deliver_ call were one line, it qualifies for the Controller. But... >> >> The delivered template is itself a View. Hence it should be dumb. Hence >> anything >> powering it belongs in the _Model_, where fat things belong. >> >> -- >> � �Phlip > > > Opinions opinions, oh my! > > As I guess has been the general theme of this thread, it really > depends on the context in which the mailing is taking place. If its as > simple as user clicking a button on your site and in turn some mail > goes out, that's controller domain. But if the mailing is part of some > more complex logic (simple example: user signs up; requested name > needs to be checked, perhaps an invite token counter needs to be > decremented, maybe you'll queue this ish etc, and the email goes out > at the end), then you'll call the mailer in the part of the model that > handles that processing. Send an emailing is a *general enough > activity* that there are no rules that say where you should do it in > the MVC context.
My two pence worth. This is the fundamental pronciple of MVC If something needs to happen under certain circumstances then that's business logic. It's about autonomy A browser that it can get and send information to and from the controller but it doesn't care about anything other than how to display the data and information it has been given and it doesn't care what a controller does with the info after it has sent it. All the browser cares about is that it has someone to talk to that knows what it's doing. The controller does not and should not care about how the information it sends to the browser is displayed or used. The job of the controller is to know where to get the information from and where to send it to. what happens before it gets the info and after it sends the info (to either a model or a view) is absolutely none of the controllers business at all. All a controller should need to know is what model to use to get and send what information to. The job of the model is to get data from a source, manipulate that data into a format that whatever wants to use it makes sense and send it there again what happens after it has been sent and received is nothing to do with the model. The model should know which storage engine to use but how that storage engine works internally is nothing to do with the model. Putting business logic like this into a controler is like asking a model to know how to the job of the database engine. It's just plain wrong. Think about it. Views are meant to view data, controller control where the data is sent to and from and models model the data and determine what happens when data is in diffewrent states, databases store data and retrieve data. It's a no brainer. What would happen if you built a rake task that did something with your data? Would you expect the task to have to know which controller and action irt should use or should it simply go get the data from a model and send that data back to the model and have evereything work as it should. James -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ 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@googlegroups.com To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
