Decoupling email templates from drip

[sssbox]

What do you guys think about allowing third party email content compilers to be used?

We currently use https://github.com/bradwhittington/django-templated-email for sending emails which is great (basically, you define the email in a django template file which can extend other templates, and send the email by referencing the template's filename).

The issue is it would make the easiest case harder probably, unless optional subject_template and body_html_template fields are left in the Drip model.

Other, less wasteful (no optional TextFields) options:

1. I could be to make a OneToOneField from a new model DripEmailTemplate to Drip and add it as an Inline to the Drip admin in addition to an optional "template_name" field to send to django-templated-email.
2. It may also be harder for the easiest case, but DripEmailTemplate could be referenced from a optional ForeignKey in Drip which would allow you to have multiple Drips use the same DripEmailTemplate

I'd be willing to take on this project but wanted to see if I could get it to work for more than just us.

[bryanhelmig]

Interesting. What are the major benefits of using django-templated-email? We already run the subject_template and body_html_template through the full Django template system which has include, load, extends, blocks and all other tags are all accounted for. I think I am missing something here!

[sssbox]

Yeah, it could just be us, that's a decent solution, but it could get annoying to not easily be able to search all templates and edit them all at the same time in something like vi, though I do understand that not all companies have content creators that know enough and are trusted enough to be able to play around in the codebase without breaking anything.

Also, I don't know if automatically converting html -> text rather than the other way around, or better, explicitly defining both, is the right way to go. The issue being if you want to have <a href="very long link">Unsubscribe</a> in html and Unsubscribe: very long link in plain text, that's impossible with all but the last case, and in fact, any links at all have to be in the format <a href="very long link">very long link</a> for all but the last case.

[bryanhelmig]

Good call on the link bit, I'll open an issue on that (opened issue #9).

[kmtracey]

I've got a similar customization need in a closely-related area: in my case I need to be able to customize the email class that is used for creating the email message. (For specifics, I'm trying in integrate use of django-drip with https://github.com/brack3t/Djrill, and in order to take advantage of any Mandrill stuff I need drip to build emails that are DjrillMessage instances rather than EmailMultiAlternatives). I was thinking of possibly proposing an ability to specify a custom class to use instead of EmailMultiAlternative, but seeing this request for template decoupling I wonder if one point of customization could serve both these needs.

What would you think of an approach that involved factoring out much of what build_email does into an independent class (which would be the default class used by django-drip, but could be overridden via settings). This class would be handed the user and drip instances, and would have methods to retrieve context (maybe?), subject, (html) body, plain text version, and to retrieve the email message instance with a send() method. build_email could then just defer to this class for the specifics of the email that is created, and users could customize the email content by subclassing the default class and overriding any of the methods where they need behavior different than default. build_email would still be responsible for doing the SentDrip creation and calling send() on the retrieved email instance, if necessary.

[bryanhelmig]

Closed the PR associated, sorry for the silence for so long! Please reopen or make a new issue w/ reference if we want to continue the convo here!