Am 13.02.2010 um 13:18 schrieb Brian Rosner:
> Hey all —
>
> I've been doing some thinking lately about how we handle events in Pinax. Let
> me first define an event. An event is an occurrence of a voluntarily action.
> Examples of these include:
>
> * user A joined project B
> * user A updated their avatar
> * user A became friends with user B
>
> Currently, we have blurred the line between an occurrence and action taken
> from the occurrence. This is called django-notification. There is overlap
> between the way we are handling this and something like an activity stream.
> We have on-site notifications which try to emulate an activity stream, but
> in my opinion fails horribly at it. Notifications must be sent to users. This
> becomes problematic when the action you want to take is to notify an IRC
> channel for example.
>
> I'd like to propose a change. At this point this change won't be in
> django-notification. Just replace its use as the event emitter. It had been
> discussed in the past to use signals. I think this is a good use-case for
> using them.
Full ack. Let's do this.
> I see two direct benefits from this approach:
>
> * don't need to enforce apps to optionally support django-notification
> * listener code is project-level which can depend on anything the project does
> (solves cases like when avatar is updated let all friends of the user know
> they've updated their avatar)
>
> To demostrate (code style below designed for brevity):
>
> # django-avatar signals.py
> import django.dispatch
> avatar_updated = django.dispatch.Signal(providing_args=["user", "avatar"])
>
> # django-avatar views.py
> from avatar import signals
> def change(request, ...):
> ... code that handles request and makes Avatar object
> signals.avatar_updated.send(sender=request, user=request.user,
> avatar=avatar)
> ... rest of view ...
>
> # project-level app (no name decided yet, but working name is
> request_events)
> # handlers.py
> from notification import models as notification
> from friends.models import Friendship
> def avatar_updated(sender, **kwargs):
> request = sender
> ctx = {
> "user": kwargs.get("user"),
> "avatar": kwargs.get("avatar"),
> }
> notification.send([request.user], "avatar_updated", ctx)
> friends = f["friend"] for f in
> Friendship.objects.friends_for_user(request.user)
> notification.send(friends, "avatar_friend_updated", ctx)
> # models.py
> import avatar.signals
> from request_events import handlers
> avatar.signals.avatar_updated.connect(handlers.avatar_changed)
>
> I'd like to gather thoughts from people. Based on the advantages
> above this seems like a win to me. If we are in agreement with the direction
> of this change I plan to integrate this at PyCon for 0.9 alpha.
Maby we should also switch notification.models.send from being a custom
implementation to a signal itself, e.g.:
# notification/signals.py
notification = django.dispatch.Signal(providing_args=["user", "extra_context",
"on_site", "queue", "now"])
# notification/models.py
from notification import signals
def send_handler(sender, *args, **kwargs):
queue_flag = kwargs.pop("queue", False)
now_flag = kwargs.pop("now", False)
assert not (queue_flag and now_flag), "'queue' and 'now' cannot both be
True."
if queue_flag:
return queue(*args, **kwargs)
elif now_flag:
return send_now(*args, **kwargs)
else:
if QUEUE_ALL:
return queue(*args, **kwargs)
else:
return send_now(*args, **kwargs)
signals.notification.connect(send_handler)
def send(*args, **kwargs):
"""
Backwards compatible, lalalala
"""
users, label = args
kwargs["users"] = users
signals.notification.send(sender=label, **kwargs)
--
You received this message because you are subscribed to the Google Groups
"Pinax Core Development" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pinax-core-dev?hl=en.
