Open spookylukey opened 3 years ago
im pretty sure this is more a "hack" than a solution but i think i'm not able to do the things @spookylukey has suggested without breaking djoser. i think sunscrapers has to coordinate that refactoring.
but in the meantime i'm knocked out by this issue so i made this: https://github.com/sunscrapers/django-templated-mail/pull/29
@thelittlebug Thanks so much for your reply, and #29 does look like it will at least provide a solution for https://github.com/pinax/django-mailer/issues/144
The current implementation inherits from a Django EmailMessage class and then adds stuff, including adding
request
and inheriting fromContextMixin
. This has several issues:ContextMixin
is designed for views, and this class has got nothing to do with views, so this is a really unhelpful mixing of completely different layers in my opinion. I cannot see thatContextMixin
is adding anything here.request
as an attribute breaks the ability of the resulting message to be pickled, which breaks django-mailer - see https://github.com/pinax/django-mailer/issues/144 which means that people can't use djoser with django-mailer.This is what I think the overall process looks like:
request
object orSite
object to populate some context data variables.EmailMessage
and return it, using only the public interface of EmailMessage (or EmailMultiAlternatives) to construct the message.None of this requires subclassing EmailMessage. I think a good API would be just this:
This gets rid of subclassing and defining
get_context_data()
- passing in the context directly is a far superior API than subclassing and overriding methods.I'm willing to bet that the resulting code will be significantly clearer (no passing things around implicitly on
self
etc) if done this way, and also probably a bit shorter, while avoiding all the issues described.