Using Signals as hooks

[Wiiboy]

I'm a bit of a noob at Web Devlopment (as you already know if you've
read any of my posts on here).

I've read that using hooks in key places in a website can help ease
future development. Can/Should Django's signals be used for that
purpose?

If so, to what extent should they be used? For example, on my site
where users submit articles for a newsletter, one place to put a hook
would be after an article is submitted. Would sending emails to
admins about the new submission, as well as emails to the users who
subscribe to be notified of new submissions be put in a separate
function, as part of the hook, or part of the page?

[Kenneth Gonsalves]

On Thursday 25 June 2009 10:24:12 Wiiboy wrote:
> I'm a bit of a noob at Web Devlopment (as you already know if you've
> read any of my posts on here).
>
> I've read that using hooks in key places in a website can help ease
> future development. Can/Should Django's signals be used for that
> purpose?

try it out - if it works do it. If it doesn't, don't do it.
--
regards
kg
http://lawgon.livejournal.com

[Wiiboy]

It works.....

[Rajesh D]

This really depends on how many users have subscribed. If it's in the
thousands then sending an email inline (be it via signal hooks or
directly in a view or in a model.save) is going to cause some problems
to the user who just submitted an article; that user will now have to
wait for the entire emailing loop to complete before his/her request
completes. So if you have scalability concerns like this, you might
want to look at an offline-messaging-based architecture where a signal
hook writes out a special message to a work queue, an offline/cron
scheduled job periodically reads from the work queue and gets the
heavy weight lifting done without bogging down your HTTP requests.

Going back to your original question, signals are a great way to hook
in event driven functionality into your apps. It allows you to keep
your event processing code separate from your models, forms, or views.
That's usually a good thing. Signals also allow you to add processing
to a third-party django app without modifying the app's code.

[Wiiboy]

Thanks.

On the topic of scaling, my site hasn't even been publicly released
yet. However, I'll keep your advice in mind as I work on it, to keep
it "future-proof".

[Wiiboy]

Question: how often should I have a cron job work to send emails? Or
should I just have it so that a few items from a task DB are done each
request (e.g. split up emails into groups, and email them a few per
request)?

[Rajesh D]

On Jun 25, 10:49 pm, Wiiboy <jordon...@gmail.com> wrote:
> Question: how often should I have a cron job work to send emails?  

Depends on the volume of emails and the frequency with which new
articles are submitted to your site. Just try a frequency of say every
10 minutes and adjust it up or down when you have real-life data to
work with.

> Or
> should I just have it so that a few items from a task DB are done each
> request (e.g. split up emails into groups, and email them a few per
> request)?

It doesn't feel like a "clean" approach to me to do this in the
request cycle. But if it's a small and low volume app and you are the
only developer managing it, you could get away with it :)

-RD

[Wiiboy]

> But if it's a small and low volume app and you are the
> only developer managing it, you could get away with it :)

You hit the nail on the head ;)

[Alex Robbins]

> should I just have it so that a few items from a task DB are done each
> request (e.g. split up emails into groups, and email them a few per
> request)?

Hmm...what happens if there aren't any requests for an hour? Does the
queue processing stop during that time? I can't get my email until
there is web traffic on the server? That doesn't seem like a good
idea.

You could look into http://code.google.com/p/django-chronograph/. I
have found that really helpful to automate jobs in the background. (It
also has a link to a nice mailer app on the front page.)

Hope that helps,
Alex