Support for backend email template variable sending.

[avelis]

Mandrill uses a concept called merge_vars, SendGrid template variables are called substitutions, and Postmark has a TemplateModel concept.

While all three services receive template variables differently within their API, they have a common philosophy on setting programmatic key value pairs to leverage on their respective services.

What does that look like via the EmailBackend framework, I am not sure at the moment. However, I think this feature request can fall within the scope of this library.

[diwu1989]

it feels over-engineered to have a flow that goes like:
django template -> anymail normalized template -> ESP template -> actual rendered email

Django already has built in templating abilities, why not just use that?
django template -> actual rendered email

just feels like a heavy maintenance cost and lots of surface area for bugs to have to normalize the templating across vendors

[avelis]

@diwu1989 For the most part I agree with you. The one area that this request tackles well is bulk transactional email sending. It is somewhat specific but has performance efficiency by allowing the ability to scale one ESP call to include a big data set to send out.

I do understand that it can lead to more bugs than it's worth. But as long as I communicated it's need then I have done what I can to ask for it.

As a solution (for my purposes) I subclassed the Payload & Backend classes to facilitate these needs.

[medmunds]

There are definitely some cases where filling in ESP templates -- stored and maintained at the ESP (not normalized from Django templates) -- makes sense. (We ran into this with Djrill, too.) Examples in #5.

I'm closing this as a duplicate of #5, to keep the discussion in one place.