brack3t/Djrill — pull request #13 by medmunds (2012-12-05 01:48:14+00:00)
Title: Expose most Mandrill API send features on EmailMessage objects

This pull request includes a bunch of changes, the primary purpose of which is to expose (nearly) the *full* set of Mandrill message/send API features on *any* EmailMessage (or derived) object.

There are corresponding updates to the readme and the tests (which account for the bulk of the deltas).

I went with additional properties on EmailMessage (duck-typing/expando), rather than continuing to expand the DjrillMessage class, because it makes it easy to work with other Django apps that want to extend EmailMessage. (E.g., there are apps that add a TemplateEmailMessage or similar, for creating messages from Django templates.)

I've left DjrillMessage in place for compatibility, but there should be no need to use it with these changes.

The Djrill backend gets refactored to convert an EmailMessage to a Mandrill API message_dict in three parts:
1. `_build_standard_message_dict` for standard EmailMessage features
2. `_add_mandrill_options` for our Mandrill-specific extensions
3. `_add_alternatives` for the HTML

I took liberties in converting some of the verbose Mandrill API syntax into simpler, more-pythonic data types for things like merge_vars and recipient_metadata. (Mandrill's arrays of name/value objects can be specified to Djrill as a simple python dict.)

Changelist:
* Support additional Mandrill send-API attributes on any ``EmailMessage``-derived object -- see details in readme
* Remove need for MANDRILL_API_URL in settings (since this is tightly tied to the Djrill code)
* Readme cleanup; mark code for python syntax coloring
* Remove ``DjrillMessage`` from the readme (but not the code or tests) -- its functionality is now duplicated or exceeded by standard EmailMessage with additional attributes
* Ensure send(fail_silently=True) works as expected
* Replace ImproperlyConfigured with appropriate exceptions in a couple more places