Application signals #6

Closed
zsiciarz opened this Issue Oct 24, 2011 · 2 comments

Comments

Projects
None yet
2 participants
@zsiciarz
Owner

zsiciarz commented Oct 24, 2011

Define custom signals, in a way similar to django.contrib.comments. These may be used then to display notifications after successful submission or to plug a spam filter in.

@tgecho

This comment has been minimized.

Show comment
Hide comment
@tgecho

tgecho Jan 5, 2012

Contributor

I like this. I wonder though, should it be in the view or in the form itself? I'm pretty sure I'll always use the form with the provided view, but if I wanted to use it somewhere else, there wouldn't be any signals. Also, it could be nice to have an after_send signal. It could be used to stick an already filtered message in the db, or whatever else you wanted.

Contributor

tgecho commented Jan 5, 2012

I like this. I wonder though, should it be in the view or in the form itself? I'm pretty sure I'll always use the form with the provided view, but if I wanted to use it somewhere else, there wouldn't be any signals. Also, it could be nice to have an after_send signal. It could be used to stick an already filtered message in the db, or whatever else you wanted.

@zsiciarz

This comment has been minimized.

Show comment
Hide comment
@zsiciarz

zsiciarz Jul 2, 2012

Owner

Oh snap, I was sure I wrote a response before... well, better late than never. In my opinion the before_send signal fits better with the view. First, it needs access to the current request (for spam filters etc), and that ties it rather with the view layer. Second, signal handlers may return False to indicate a rejected message, in which case the view returns HTTP 400 status code.

As for the after_send signal, I added it to be sent from the processed form, providing two arguments - the EmailMessage object, and the form itself (not sure if neccessary) - commit fcba4e1. Feel free to review that part.

Owner

zsiciarz commented Jul 2, 2012

Oh snap, I was sure I wrote a response before... well, better late than never. In my opinion the before_send signal fits better with the view. First, it needs access to the current request (for spam filters etc), and that ties it rather with the view layer. Second, signal handlers may return False to indicate a rejected message, in which case the view returns HTTP 400 status code.

As for the after_send signal, I added it to be sent from the processed form, providing two arguments - the EmailMessage object, and the form itself (not sure if neccessary) - commit fcba4e1. Feel free to review that part.

@zsiciarz zsiciarz closed this Feb 2, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment