The point of any event system is that the subscribers are decoupled from the publishers. In your example it seems you're mangling the concept of an event to mean "publish" and it's heavily coupled to the "do_something" listener.
Anyway the point is that Pyramid has a pub/sub system within it that works via the ZCA. If you don't want to use it you're more than welcome to implement your own thing. Pyramid won't care one way or the other, it just depends on your needs. On Wed, Dec 14, 2011 at 5:15 AM, jerry <[email protected]> wrote: > Thanks Michael and Chris. > > From the framework design point of view, such event system is > invaluable. But for application development, I fail to see its added > value compared to simple function call. And it makes parsing variables > harder. > > E.g., I'd naively design Michael's example as -- > > class MyEvent(object): > def __call__(self): > do_something(v1, v2, ...) > > def do_something(*args, **kw): > # do stuff > > e = MyEvent() > e() > > Any enlightenment will be much appreciated. > > Jerry > > On Dec 14, 5:25 pm, Chris McDonough <[email protected]> wrote: > > On Wed, 2011-12-14 at 01:11 -0800, jerry wrote: > > > I would appreciate some confirmation/explanation on the Pyramid event > > > system -- is event/subscribe restricted to Pyramid running on one > > > physical server? > > > > Yes. > > > > - C > > > > > > > > > > > > > > > > > > > > > Thanks. > > > > > Jerry > > > > > On Dec 14, 7:13 am, John Anderson <[email protected]> wrote: > > > > On Tue, Dec 13, 2011 at 5:10 PM, Vlad K. <[email protected]> > wrote: > > > > > > > Hi all! > > > > > > > In my Pyramid app I want to implement an event system, basically > for > > > > > plugins to hook to various events that raise in the life of the > > > > > application. These events are each different, some allow one hook > (by > > > > > raising an exception if another hook tries to register for same > event), > > > > > some many, they handle various kinds of data, etc... My approach > is the > > > > > following: > > > > > > > class SomeEvent(EventBase): > > > > > """Event raised in this or that condition, does X, requires Y, > ...""" > > > > > HANDLERS = [] > > > > > > > @classmethod > > > > > Register(cls, callable): > > > > > """Decorator that registers a handler for this event.""" > > > > > cls.HANDLERS.append(callable) > > > > > return callable > > > > > > > def __init__(self, request): > > > > > self.request = request > > > > > ... > > > > > > > def dispatch(self): > > > > > for h in self.HANDLERS: > > > > > h(self) > > > > > ... > > > > > > > @events.SomeEvent.Register > > > > > def some_handler(event): > > > > > ... > > > > > > > So basically we have a plugin with a handler some_handler, which we > > > > > register for the particular event via its decorator. Now, I don't > want to > > > > > reinvent the wheel, and this approach seems rather straightforward, > > > > > unit-testable and simple to implement, plus the events are then > > > > > self-documenting. I was wondering if there is a better solution, > or perhaps > > > > > I can reuse some part of the Pyramid framework? ZCL? > > > > > > > Also, can I reuse Venusian to scan the plugins package and thus do > "auto > > > > > import" of plugins at app startup time, instead of having the > requirement > > > > > to manually import each plugin so that the decorators would > trigger and > > > > > register the handlers (I really want the "plug and play" solution > with > > > > > dropping a module in the plugins package dir and calling it done)? > > > > > > > Thanks. > > > > > > You can use: > http://docs.pylonsproject.org/projects/pyramid/en/latest/api/events.html > > > > > > this is how you would create custom events: > https://github.com/sontek/pyramid_signup/blob/master/pyramid_signup/e... > > > > > > this is how you would fire the event: > https://github.com/sontek/pyramid_signup/blob/master/pyramid_signup/v... > > > > > > and this is how you would subscribe to the event: > https://github.com/sontek/pyramid_signup/blob/master/pyramid_signup/t... > > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" 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/pylons-discuss?hl=en. > > -- You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en.
