We do something very similar to this in Spacebook. It made code-reuse much easier and integrating of third-party applications rather trivial. In retrospect, I should have made this suggestion myself many months ago.
So anyway, I'm +1 and I would like to work on this at Pycon. Danny On Sat, Feb 13, 2010 at 7:18 AM, Brian Rosner <[email protected]> wrote: > 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. > > 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. > > Brian Rosner > http://oebfare.com > http://twitter.com/brosner > > -- > 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. > > -- 'Knowledge is Power' Daniel Greenfeld http://pydanny.blogspot.com http://dannygreenfeld.blogspot.com -- 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.
