Custom sender

[brad]

Hey guys,
I needed to send drips via SMS, so I modified django drip to make things more generic and allow custom senders.
After submitting this request I realized it would probably be better to create a new migration rather than edit existing ones. Before I do that though, I want to gauge interest. Is this even a feature you want?
Here is the documentation for the new feature (also added to the README). I suppose some new screenshots would also be needed.

---

Custom Sender

If you want to send messages different from the default sender (SMTP),
you can create a custom sender class that inherits from SenderBase. For example:

from drip.models import SenderBase

class CustomSender(SenderBase):
    # drip is the drip.drips.DripBase object which gives access to
    # from_address and from_address_name
    def send_message(self, drip, user, subject, body, plain):
        # Custom sending logic (SMS, in app messaging, snail mail, etc.)
        ...
        # Return a boolean indicating if the message was sent or not

After adding this table to the database using syncdb or a south migration, you
will need to create an object of this type:

$ python manage.py shell
>>> from exampleapp.models import CustomSender
>>> sender = CustomSender()
>>> sender.name = 'My Custom Sender'
>>> sender.save()

Now when you create a Drip in the django admin you will have the option of
selecting your own custom sender. When these Drips go out, django drip will
send the message with your custom sender instead of the built-in method.

---

[bryanhelmig]

Interesting. I'll take a look at this when I get some time, but I don't see any problem with the concept!

[kmtracey]

Do you really need the ability to change senders per drip? I too also needed the ability to change something about the email sending, and also possibly something about the details of the email built, which touched on #8 so I commented there. The approach I've taken (which I haven't created a pull request for, lacking feedback on #8 and time to revisit) is to allow a custom email-building class to be specified in settings. So an install can subclass the base default class provided by django-drip for this, and customize any aspect of the email that is created. But it's an install-wide thing, it does not allow the admin user to change class used per drip. Here's a pointer to what I've done to have custom email behavior:

caktus@10f031b

[brad]

Yes @kmtracey, we actually do need this on a per drip basis. Some messages will be delivered via email, some via SMS, and in the future some may be delivered via in app messaging or some other notification type. I love what you've done though. It's very close, but not quite what we need.

[kmtracey]

This change behaves unexpectedly for sufficiently large lengths:

>>> x256 = ['x' for x in range(256)]
>>> x257 = ['x' for x in range(257)]
>>> len(x256) != len(x256)
False
>>> len(x256) is not len(x256)
False
>>> len(x257) != len(x257)
False
>>> len(x257) is not len(x257)
True
>>> 

is compares the ids of objects, sufficiently small integer values have an invariable id value (which is likely an implementation detail and not to be relied on), but large enough integer values do not have an invariable id:

>>> id(len(x257))
18775136
>>> id(len(x257))
18775088
>>> id(len(x257))
18775136
>>> id(len(x256))
18235008
>>> id(len(x256))
18235008
>>> id(len(x256))
18235008

[brad]

Wow, that's very interesting, I didn't know that! I Thanks @kmtracey, I changed it back. I will have to be much more careful where I use is in the future.

[kmtracey]

I'm thinking we could combine the two approaches. If SenderBase was modified to incorporate all of what can be overridden in my DripEmail then we'd have a single way to allow for whatever customization of the email building & sending was needed by a particular install.

For my needs having to have the admin user specify something about the "sender" per-drip is a negative, since for me it's always supposed to be one particular class that handles the building/sending. Having to have the admin specify it is just a way to allow for mistakes. So I'd like to come up with some way where for the case of "all drips have same building/sending characteristics, but not django-drip default)" the admin is not given the option to choose anything...

[brad]

Great idea to combine the two ideas.

I understand where you're coming from with the admin, problem. That's why I made it an optional field, and the default is always the built in email sending. Perhaps a good compromise would be to use a global DEFAULT_DRIP_SENDER and/or DEFAULT_DRIP_BUILDER setting. Also, the per-drip setting could be moved to the bottom of the admin form and we could add some help text to indicate that you shouldn't change it unless you know what you're doing. What do you think?

[kmtracey]

Sounds good. I am travelling today so unlikely to get to working on this, but tomorrow I should have time to spend trying to come up with a combined approach that allows full customization, per-drip if needed....