[Grok-dev] Does it make sense: registering factories that are
functions not classes
Christian Theune
ct at gocept.com
Thu Jan 25 08:55:08 EST 2007
Am Donnerstag, den 25.01.2007, 13:36 +0100 schrieb Jan-Wijbrand Kolman:
> Hi,
>
>
> 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.
What about
@grok.adapter(context=, implements=, provides=)
def foo_factory(...)
asdf
?
--
gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany
www.gocept.com - ct at gocept.com - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.zope.org/pipermail/grok-dev/attachments/20070125/4655d670/attachment.bin
More information about the Grok-dev
mailing list