Decoupling email templates from drip about django-drip HOT 5 CLOSED

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!

from django-drip.

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.

from django-drip.

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

from django-drip.

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.

from django-drip.

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!

from django-drip.