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.
