[Grok-dev] grokcore.component's grok.SubscriptionAdapter and grok.SubscriptionMultiAdapter

Jan-Wijbrand Kolman janwijbrand at gmail.com
Mon Jan 31 05:13:03 EST 2011


Hi,

Last week Sylvain and me finalized his work on the generic 
Subscription[Multi]Adapter components.

I opted for writing this post, to force me to really understand what is 
going on with these components :)

Currently we do have the `@grok.subscribe()` decorator in Grok. It can 
be used for registering a function that is called when a particular type 
of object event is fired (optionally for a specific type of context object).

Confusingly enough, the terminology used under the hood for "functions 
subscribed to events" by zope.component is "handlers", as in "event 
handlers".

There's also a lesser known, more general and very useful concept of 
"subscription adapters". Subscription adapters in a way look like event 
handlers, but they're different as they're not triggered through events, 
but through a subscription adapter lookup for a context object (or 
multiple context objects). Furthermore, the subscription adapter 
components should provide a particular interface.

Another important aspect of the subscription adapters is the fact that, 
when they are called to do their work, the result of their work is 
return to the caller - unlike event handlers. As subscription adapters 
also can be ordered, one can build processing pipelines with this concept.

grokcore.component introduces two new components - 
`grok.SubscriptionAdapter` and `grok.SubscriptionMultiAdapter` - and an 
additional use for the existing `grok.subscribe()` decorator. Whenever 
the `grok.subscribe()` decorator is used together with the 
`grok.implementer()` decorator, the function is grokked as a 
subscription adapter::

   @grok.subscribe(IFoo, IBar)
   @grok.implementer(IBaz)
   def my_multi_subscription_adapter_function(foo, bar):
     return something_providing_IBaz

We had quite some discussions on the naming scheme, including 
considering renaming the current event handler-specific use of 
`grok.subscribe()` into `grok.eventhandler()`, but settled with reusing 
the `grok.subscribe()` decorator.

Anyway, the branch for this work is almost finished and about to be 
merged. If people have suggestions or remarks, we'd glad to hear it.

regards, jw






More information about the Grok-dev mailing list