If you know the list of subscribers for each event when coding the
event, your approach works. But if you want to allow plugins or other
packages to hook into the events, it breaks down.
I'm using events to allow for configurable notification emails. Some
configurations of the application will have many of these, others
none, etc.
regards
robert

On Wed, Dec 14, 2011 at 12:15 PM, 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.

Reply via email to