[Grok-dev] Re: Does it make sense: registering factories that are functions not classes

[Philipp von Weitershausen]

Christian Theune wrote:
>> In Grok we can do this:
>>
>> class Foo(grok.Adapter):
>>     grok.context(...)
>>     grok.implements(...)
>>     grok.provides(...) # whenever implements is ambiguous
>>     ...
>>
>> The Foo class now is a factory for the adapters. But there're
>> situations where you do not want a class, but just some function to be
>> the factory. So, would it make sense for Grok to allow for this
>> (thinking out loud now):
>>
>> def foo_factory(...)
>>     grok.context(...)
>>     grok.implements(...)
>>     grok.provides(...) # whenever implements is ambiguous
>>
>>     # and now follows the body of the factory function
>>     ...
>>
>> Or maybe (I'm not even sure the previous example could work at all):
>>
>> @grok.factory(context=..., implements=..., provides=....)
>> def foo_factory(...)
>>     # and now follows the body of the factory function
>>     ...
>>
>> This could then of course be extended to work for multiadapters too.
>> Actually I now realise I came up for all of this, because I'd like to
>> register a *view* for IObject that will provide IInputWidget and is an
>> instance of ObjectWidget.
>>
>> Since ObjectWidget needs more than just a context and a request for
>> __init__ arguments, I'd like to have a factory function that creates
>> the instance (the view) of ObjectWidget with whatever argument it
>> expects.
> 
> We definitely have to support factories.

I agree, we should support functions as adapter factories.

> What about
> @grok.adapter(context=, implements=, provides=)
> def foo_factory(...)
>     asdf

This severely breaks with the semantics of zope.component.adapter and 
might be confusing (since it has the same name but does semantically 
more). I suggest using several decorators:

   class Mammoth(grok.Model):
       pass

   @grok.adapter(Mammoth)  # (works like z.c.adapter)
   @grok.implementer(IFoo) # (works like z.i.implementer)
   def fooForMammoths(mammoth):
       pass


I don't think @grok.provider isn't needed. I see no use case for 
specifying more than one interface in @grok.implementer and then 
selecting only one of them for the adapter registration. This is useful 
for a class, but not for a function.

Note that grok.adapter would be a slight variant of z.c.adapter that 
would support grok's DRY rules. Therefore, you could also leave out the 
adapted object if it's the current model:

   class Mammoth(grok.Model):
       pass

   @grok.adapter
   @grok.implementer(IFoo)
   def fooForMammoths(mammoth):
       pass


What do you think?

-- 
http://worldcookery.com -- Professional Zope documentation and training
Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5