It does feel like a more complex way to handle notifications. I like the idea of being able to attach extra listeners that have custom behavior but its not something i've needed and i think it would only be useful on a few events. In Satchmo the use of signals is for specific events that where people have needed to extend the default behavior, its not used for a general event notification.
Its a good idea but i think its best to leave signals until you need hook into a specific event. On Feb 14, 11:33 am, Ahmad Al-Ibrahim <[email protected]> wrote: > Hi Brian, > > Great you brought this up, activity stream will be a great addition to Pinax > IMO > > I started to look for a solution few months back and I couldn't find what i > wanted in Pinax. ericflo created great activity stream server > (AwesomeStream), I started to work on a client and enabled comments and > likes/dislikes, I was going to continue the work and planned to integrate it > with Pinax (django-friends and django-avatars), but I've stopped since > ericflo seemed to lose interest in AwesomeStream in-favor of Solr. What is > interesting in AwesomeStream approach, is the events are posted once and > there are no redundant copies of the event for each friend, and the stream > is retrieved based on the relation with the user, so we dont have to send > updates for each and every friend. > > My plan was to make the activity stream the home page of the user, where the > user can post updates, or read, comment, and like/dislike his friends > updates and activities, the updates or activity stream could be generated by > the user and internal/external applications. In my case I have a game server > that will be generating events based on the user activities or scores, I > wanted the activity stream to include media (images, videos, etc) and not > only plain text. > > I'm very interested in having activity stream in Pinax, and I'm willing to > spend sometime on that. > > Ahmad Al-Ibrahim > > On Sat, Feb 13, 2010 at 3:18 PM, 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]<pinax-core-dev%[email protected]> > > . > > For more options, visit this group at > >http://groups.google.com/group/pinax-core-dev?hl=en. -- 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.
