You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current implementation inherits from a Django EmailMessage class and then adds stuff, including adding request and inheriting from ContextMixin. 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 that ContextMixin is adding anything here.
It's a completely unnecessary use of inheritance in my opinion.
This is what I think the overall process looks like:
We prepare context data to be passed to a template, optionally using a request object or Site object to populate some context data variables.
We render a template, with some special code to be able to extract certain blocks, allowing us to have a single template for the subject/plain text/html parts. This part of the process would be especially easy using django-render-block (which apparently was partly inspired by django-templated-mail.)
We put these 3 parts together into an 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.
The text was updated successfully, but these errors were encountered:
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: #29
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 Having problem on django-mailer on using with djoser pinax/django-mailer#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.The text was updated successfully, but these errors were encountered: