So I thought again about my original idea, which was to anticipate the client’s needs and give them control over the content of the mail messages sent from different actions. The way I saw it, I had a choice, for one way, I could embed the method call to send the mail only when explicitly asked to do so by the client.
Because I built out a fairly robust way of storing the messages and sending them, it would become a very trivial matter for me to add more locations on request by the client, who could them edit them as they wished from the UI.
Or, as an alternative, I could just embed the call wherever I thought it might be needed in the future, since I was planning to have it test for the existence of the message and return false otherwise. So then the question becomes is the DB overhead worth it. The extra call would slow down the site a tiny bit.
To give a more concrete example of what I’m talking about. Let’s say the client wants an autoresponder on registration. The user registers and gets an email confirming it. Our class and methods, which we have not completed yet, but will shortly, will handle this beautifully. Perfect.
But looking over our template, we see that we have a contact form and wouldn’t it be cool to be able to send an auto-response whenever someone contacts us? This is standard functionality on most sites and the client might not realize it yet, but they will probably want this.
So as a compromise, we could embed the method calls to send mail everywhere we think the client will request them during development, then, after a final review with the client, remove the unused ones from the code. This creates a little cleanup work, but would actually be very simple to do.
This way, during site development, when the client begs you to add an autoresponder, you can tell them to just add the DB record via backend UI, with no additional coding required. This would keep them happy and you would be one step ahead.
Of course the level of implementation is up to you. I only mention all this because you can see that as a project progresses, things tend to change. I wanted to build a behavioral method that checked every action, but that turned out not to be realistic, so I compromised and settled for an inline action method instead.
Ok, so let’s look at what we have so far.
We can use RecordHelpers::findStatusMessage($action_name, $controller_name) to retrieve the $message_id, if a message for that action and controller exists in our DB.
We can set the mail settings based on $message_id, which includes the subject and body of the email, using RecordHelpers::getMessageSubject($message_id) and RecordHelpers::getMessageBody($message_id) methods..
We can send the mail using the MailCall::sendTheMail($message_id) method.