Hello all,
I’m wondering were should we instantiate our Zend_Mail object.
On our controller, our or model, if on our model, on our domain object, or on our mapper / dao (whatever you have to deal with your database) ?
Does it depend ?
If the email send database data, it will be on our model. If it is a simple contact form, it will be on our controller ?
Or, nothing like this, and you put it, like a service or something ?
Thanks in advance.
i’m no expert, but I would speculate that you would call the model to get the relevant db data, return that as an array and then initiate the email sending in the controller.
For example, if a “forgot password” email is sent:
// controller /user/forgotpassword
$email = $_POST['email'];
// fetch from model
$user_id = $this->findByEmail($email);
// call the email class / method inside genNewPassword
$this->genNewPassword($user_id);
This is obviously pretty incomplete and happy to hear any alternative approaches.
Are you composing your email on your controller ?
You say it’s inside genNewPassword, but it seems the instantiation itself occurs somewhere else…
And I believe we should make our effort to keep our methods up to one task, and there, you have at least two.
Generate a Password;
Send and Email;
If you need, later, to generate a password without sending an email, you have to either duplicate, or refactor.
If you need, later, to send an email only, you are repeating somehow.
I’m newbie myself so, I may be wrong.
I notice as well, that this sendMail will depend a LOT of to many factors.
Will we send a user-to-user email ?
Will we send a site-to-owner email ?
Will we call this functionality on several controllers or just one, or all ?
Guess there’s no one million dollar answer here…
I will try to look, however, to a service approach. Like:
MailService->sendActivation($user);
MailService->sendForgotPassword($user);
MailService->sendContact($siteform);
Ignoring specific zend implementation details, I think the program flow should work something like this:
The whole email sending procedure is its own MVC triad.
The output of the email is a view
All the processing goes in the model
The view reads data from the model to populate the fields
The controller reads the view’s output and sends the email (It gets the address from the model)
From a separtion of concerns point of view, the controller is the only part which knows what’s going to happen with the final output (that it’s going to be emailed). The model has zero knowledge of the output method, the view is just text/HTML so could theoretically be used anywhere.
Seems a very nice approach TomB. I was always wondering if our email composing parts shouldn’t be on a view.
About the view:
Zend as I use it, is using a controller to inject data into the view. (so a diferent approach from what you have suggested).
So, perhaps, we will have one view per mail “type”.
If they happen to have similar information, I can create a layout.
About the Model I:
The model (where on the model? Considering a data mapper design pattern, despite our good will, this has nothing to do with mapping a data source into a domain object, so, perhaps, we should have it on our domain object (that at the present only contains getters and setters)? Or, should we create another “thing” on my model do deal with it ?
About the Model II:
Depending on our application email needs, we may have our emails stored into a database (if we will send emails to registered users for example), or having them on a configuration file (if we are dealing with contact forms cross the web application).
Either coming from a database or from a xml file or ini or whatever, we are talking about data sources somehow, so, the model, seems to fit here quite nicely as well, yes?