Organizing Emails Logic into a Service

Hey Kiuega

You'll need to get the Symfony\Component\Asset\Packages service and call getUrl() on it, passing the path to your build, final asset (ignoring that's versioned), e.g. $packages->getUrl('build/files/manuel.pdf')

Besides, is it a good solution to attach a file from the public folder, or is it better to leave it in the assets?
Well, that depends on your needs. If you need that asset to be accessible through the web, then, yes, it should live in the public directory. If not, then, making it private makes more sense

Cheers!

Hey Thibault V.

That's a good question and this is how I would do it

I would create 2 entities. User and EmailCategory
A User would have a ManyToOne relationship to EmailCategory, so a User can subscribe to many categories

Then, depending on the situation, I would create an interface or a command where I can specify which categories I want to send my email. Then, I would create a query that fetches all the users that are related to any of the categories I specified, and from this point, you already know the rest, you only have to create the email body and send it

I hope it helps. Cheers!

FYI: I currently decided to do the following
1 - Define a parent Mailer service with send() method which includes $category private param (with default value) and a verification for the category with user settings inside it.
2 - Define a child Service that extends Mailer for every group of emails. Example :
<br />Account updates emails => AccountUpdatesMailer extends Mailer<br />Blog emails => BlogMailer extends Mailer<br />Security emails => SecurityMailer extends Mailer<br />...<br />
3 - Each child service defines $this->category to the corresponding group (for my example: account_updates, blog ...)

What's your opinion on this organization with services ?

thanks in advance for your opinion

Hey Thibault V.!

Sorry for never replying on this! For some reason, your comment got marked as SPAM and we missed it! In general, I like your solution. There is no need to hook into Messenger or Mailer in some fancy way. Instead, your solution simply creates 3 new services: each which contains the special logic you need, and then calls the normal Mailer. We do this kind of thing all the time.

The one modification I would make is this: instead of extending Mailer, I would make your classes extend nothing and instead, accept Mailer as an argument to your constructor. The only difference would be that instead of calling parent::send(), you would eventually call $this->mailer->send().

The reason for this is just that having a separate class (that doesn't extend Mailer) keeps things cleaner and simpler. You don't need to worry about the parent Mailer constructor or even using service decoration: your BlogMailer would be a normal service that automatically autowires the mailer service thanks to the MailerInterface type-hint in your constructor. This is also an example of "composition over inheritance" if you want to get really nerdy about it ;). What you would be doing is called object composition.

Cheers!

Hey geoB,

Yep, we will do it later in this course. The final code from this course do have "return $email" line, I just double-checked :)

Cheers!