Extending SES to support setTemplate and passing data to the template.

[shadow-fox]

Hi, My primary usage for the mail is using AWS SES . While this module supports that, but I don't see anywhere to set a template for the same. I am not sure how to do this. Would be great if someone could outline how to extend it so that it will support setTemplate and passing data to the template page . It would be great if the module starts supporting sendy.

[bakura10]

Hi,

SlmMail is only a thin wrapper around various emails API providers. It does not do any rendering of templates. AWS SES does not support templates natively. If you want to use templates, you can use providers that support them like Mandrills.

[shadow-fox]

Hi @bakura10 What I want to achieve through this is : I would like to use a view with variables defined, when sending mail, i would like to use that view and pass all the variables that is required. Is that possible with SlmMail ?

[bakura10]

No, it's not possible with SlmMail and that's out of the scope of this module. iirc there is a module for that but I can't remember its name. @juriansluiman ?

[juriansluiman]

@shadow-fox I am not quite sure what you want, but SlmMail only provides the transport layer. There are many e-mail modules for ZF2 and some of them provide a rendering part. Those modules allow to inject a given transport (hence, use SlmMail in this case) and given some variables and a view template, they will render a HTML view for you. Satisfies the combination of SlmMail + any other module rendering email templates you?

Perhaps I am misunderstanding your requirements, if so, please explain more in depth what you expect from SlmMail to support Amazon SES :)

[shadow-fox]

@juriansluiman Sorry if I am not clear in what I am expecting out of this module. Thanks for the reply, I will come back with more clear question. For now I think I will have to look for another module which supports rendering a view to use as email template.

[shadow-fox]

If I can bother you with one more question, if I happen to use another module for rendering template like acelaya/ZF2-AcMailer , then how would I do it ?

[juriansluiman]

Reviewing ZF2-AcMailer is too limited in this aspect. It explicitly only supports sendmail and SMTP: https://github.com/acelaya/ZF2-AcMailer/blob/master/src/AcMailer/Options/MailOptions.php#L101-L126

You should find a module which is agnostic for its transport layers. Most services simply do new SmtpTransport or so or accept different transports (like the module you found) but then that's too limited. The only one I found so far is MCNEmail and you have to overwrite his factory by the factory from SlmMail. If you have both modules installed, this line in your module.config.php should be sufficient:

'Zend\Mail\Transport\TransportInterface' => 'SlmMail\Factory\SesTransportFactory'

Something similar would probably work for zf2-mail and GoalioMailService as well.

[veewee]

@shadow-fox I encountered the same issue. I just wanted an easy to use mail-manager, that focuses on building the mail itself. When I want to send an e-mail, I don't want to worry about the Mail classes like Transport, Message, ...

That is why I started a project called mail-manager. You can create and fully configure your e-mails in a custom 'MailPluginManager'. It should be very easy to add your own transport adapters and I am planning to use it in combination with SlmMail (Mandrill) in the future.

Maybe you can take a look at: https://github.com/phpro/zf-mail-manager

Note: There is still some work that needs to be done, but it is already usable as-is.

[juriansluiman]

We're now planning to extend Soflomo\Mail with a "service" which helps to write mails. The transport is injectable so the default config style is maintained or you inject any of the SlmMail transports. However, all is planned but not started :)

[juriansluiman]

@shadow-fox @veewee We have had some time to update Soflomo\Mail, so v0.2.0 is tagged: https://github.com/Soflomo/Mail

I have made a short section in the README how to use Soflomo\Mail with transports from SlmMail: https://github.com/Soflomo/Mail#use-an-existing-alternative-transport-service

[veewee]

@juriansluiman Looks great! Maybe a feature that is still missing in MailService::send(): Instead of array $options, I want to use a MailInterface for more complex e-mails. Maybe both should be possible.

The issue is: when sending an e-mail, the body can contain data from specific services. These services are not needed by the service/controller that is sending the e-mail. So it better to create a Factory that injects the needed services in a custom class that implements MailInterface. Also handy if you want to load from / to addresses from the database. (In adition there can be an MailPluginManager which is like the service manager for loading mails)

What do you think?

[juriansluiman]

@veewee what do you mean with the MailInterface? You can supply a Message object already, if you want that? You can also set a default message which contains the additional fields you want to provide by default? You can set the from & from name already in the default message by using the config. Perhaps there is a misunderstanding, I am just trying to find out your goal.

Regarding the plugin manager, I don't think it's yet a goal of the module, but it might be an additional feature. Of what I understand, you want to have mails like "service" where you only call your service name and the other configuration (subject, templates etc) is fetched from a configuration somewhere else?

[veewee]

Not exactly. Let me try to rephrase:

At you have to:

• Create an array of options
• Optionally: Create an array of variables
• Optionally: Create a default Message and attach params

So the creation of above stuff needs to be done somewhere in a controller or service. The idea is to go a bit further and create an API for the creation part.

Let's say: I have a platform with multiple tenants who have users. When a new user registers, the from address should be the one of the tenant.

What I suggest:

• Create a UserRegisteredEmail class which is a MailInterface or whatever you name it.
• In this mailerclass you can add dependencies that are only needed to create the e-mail. In this case: tenant, user, and a service that is called: SuperMegaGreeter which is only used for the e-mail.
• This way it is possible to get the from adresses from the tenant object, the to addres from the user object, and a custom variable for the SuperMegaGreeter.
• The MailInterface will have methods like: getOptions() , getVariables(), getMessage(). Now the mail is fully configurable from a class with dependencies that are only needed to send the e-mail. (Note: I don't like the getOptions() in this case, but like to use getTemplate(), getSubject(), ...)
• Now on the MailSender service I want to send this class instead of calling the three methods.
• Extra: An instance of the UserRegisteredEmail can be fetched from a MailManager (like the service manager, with invokables, factories, ...)

I know it CAN be done allready, but it is a lot faster for RAD + easier to use because you don't need to know how the MailSender works exactly.

[juriansluiman]

What about this:

use Soflomo\Mail\Service\MailService;
use MyApp\Entity\User;

class RegistrationEmail
{
    const EMAIL_TEMPLATE = 'email/registration';
    const EMAIL_SUBJECT  = 'Welcome to mysite.com';

    protected $mailservice;

    public function __construct(MailService $service)
    {
        $this->service = $service;
    }

    public function send(User $user)
    {
        $this->service->send(array(
            'to' => $user->getEmailAddress(),
            'to_name' => $user->getName(),
            'template' => self::EMAIL_TEMPLATE,
            'subject' => self::EMAIL_SUBJECT,
        ));
    }
}

You can register this one as a service in the root service manager. You could abstract the __construct() away in an abstract class, so all your email "services" (or I'd rather say task) can utilize it.

Your idea of the plugin manager is similar to how we use jobs in SlmQueue. It might be a valuable addition, but for now it feels the complexity is only shifted because you have to have knowledge about the email tasks and its plugin manager.

[veewee]

Well yeah, I also thought about this. But it's the same issue: I have to memorize all the options parameters. Maybe I just hate working with arrays :) Another thing about this class: An e-mail is an object that can be sent or received. But an e-mail that is sending itself is a little bit strange.

But if this is the way you want people to use the module, then it is also fine by me. It already looks great as-is.

[juriansluiman]

@veewee let's continue the discussion in Soflomo/Mail#1 as it gets quite offtopic for SlmMail.

@shadow-fox closing now. If you need an email service with template rendering, I suggest you to take a look at Soflomo\Mail now.

[shadow-fox]

@juriansluiman @veewee Thank you guys. And @juriansluiman thank you for coming up with the module that fast. I will follow the discussion and will try out both to see which one fits my requirement. And once again thank you guys.