• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
[feature] Email module

#1
Thank you all for participating in the Email third part provider poll.
Our email implementation is in progress, but not the highest priority compared to the 4.0.0 release.

Planned so far:
[x] separate Email\Email class, which encapsulates an Email entity
[x] Email\TransporterInterface, which abstracts the behavior of a mail transport agent, or a wrapper for same, or even an external email service
[.] Email\Handlers\BaseHandler, which implements the common methods of a Transporter
[.] Email\Handlers\MailHandler, which uses (PHP)mail to send emails; was in CI3
[.] Email\Handlers\SendmailHandler, which uses sendmail to send emails; was in CI3
[.] Email\Handlers\SMTPHandler, which uses SMTP to send emails; was in CI3
[.] Email\Handlers\PHPMailer, adapter for 3rd party module suggested by poll
[.] revised user guide writeup for handling email
[x] unit testing for Email\Email
[.] unit testing for Email\Handlers\...
[ ] using an external email testing service for unit testing; leaning towads https://mailcatcher.me/

----------------------------------------------------
This is a roadmap feature, or "epic", and a card on the roadmap board.
Component tasks will show up as issues or PRs on the development board.
We welcome comments & suggestions below.

PHPMailer looks like an important choice for the CodeIgniter community, and a complete solution.

The big difference between PHPMailer and the in-progress Email module for CodeIgniter4 is that we have separated the Email and the handling classes, unlike PHPMailer and the CI3 implementation, which bundle them together into a single class (with supporting classes).

We could just use PHPMailer and be done with it, or we can continue on the current path, which would allow the use of a number of mailers with minimal code change.

What do you think?
Reply

#2
Thanks for this write up! I don’t know if this was prompted in part by my comment, but this is exactly the info I was looming for.

I’m pretty ignorant about the different mail handlers and why you would use one over the other. I like the idea of having a common class that could call any of the different implementations, useable with minimal to advanced configuration. My current projects use SMTP or an already-configured server email.
Reply

#3
I prefer the current path, which would allow the use of a number of mailers with minimal code change.

I'm a fan of keeping it simple.
Reply

#4
I prefer that the CI Email class be a simple API to typical server MTA's, e.g. bin/mail, Sendmail, Postfix, SMTP. Essentially the same abilities as CI v3.

I think it's a mistake to write an abstraction layer that tries to handle anything more complicated. Any such class will quickly become overweight and difficult to configure. But hey, that's just me.
Reply

#5
@dave_friend The intent is not an abstraction layer, but rather refactoring. Adapters would take the current refactored API and redirect calls to other providers, that's all. If the other providers don't "fit" our API, that would be a new can of worms.
Reply

#6
Even after using PHPMailer and other php mail libraries for years, my favorite is CI3's built-in email library!

(04-30-2019, 04:22 PM)ciadmin Wrote: @dave_friend The intent is not an abstraction layer, but rather refactoring. Adapters would take the current refactored API and redirect calls to other providers, that's all. If the other providers don't "fit" our API, that would be a new can of worms.

(Using CodeIgniter since 1.x)
Reply


Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  


  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2019 MyBB Group.