[Zope-dev] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)

[Lennart Regebro]

Also, the decorators will always return the original component,
meaning they can easily be used as post-config:

@adapter(IMyFace, IMyFeet)
class FootInMouth(object):
    ...

Will mark the class as an adapter, but not register it.

@adapt(IMyFace, IMyFeet)
class FootInMouth(object):
    ...

Will mark and register.

@adapter(IMyFace, IMyFeet)
class FootInMouht(object):
    ...

adapt(FootInMouth)()

Will register a previously marked adapter, and

adapt(FootInMouth)(IMyFace, IMyFeet)

Will mark and register. This means you can, if you want, still have
the interfaces in one file, the implementations in one file, and the
registrations separately (say, configure.py), thereby getting the same
separation as you had with interfaces.py, components.py and
configure.zcml. Your package just needs to *not* import the
configure.py file.



On Mon, Mar 21, 2011 at 12:47, Lennart Regebro <regebro at gmail.com> wrote:
> I haven't read through the whole discussion in detail, so I'm sure I
> repeat some of what has been said already, but here is my point of
> view.
>
> 1. Yes, Grok is pretty implicit. If it's soo implecit is a matter of
> taste, but much of the implicitness makes sense. You typically do have
> a model and a view and a template, and the model and view are
> typically in one module, and has a name similar to the template. That
> implicitness however only makes sense in the specific context of web
> applications. There is no reasonably way to have that implicitness
> with components and adapters. So a configuration for the ZCA in
> general can't be implicit.
>
> 2. That doesn't mean we can't use grok-style configuration though.
>
> 3. Although Python 3 means we can't. We'll have to use decorators.
>
> 4. zope.interface already does, and zope.component will as well, once
> it's ported. That means we get things like:
>
> class IMyFace(Interface):
>    whatevah
>
> class IMyFeet(Interface):
>    something
>
> @implementer(IMyFace)
> class MyFace(object):
>   yeahyeah
>
> @adapter(IMyFace, IMyFeet)
> class FootInMouth(object):
>   def __init__(self, mouth, foot):
>       pass
>
> The @adapter decorator so far only handles functions, but will be
> extended to classes once we port zope.component. I think also adapter
> today will only mark the object as adapts(...) does, but you will
> still use zcml to register the adapter. So probably we still need
> @adapter (as it already exists) and also another decorator (say
> @adapt() maybe?) that will both mark the class and register it in the
> registry, and hence do the same as the <adapter ... /> directive does
> today.
>
> Then we have subscriber, utility, resource and view directives.
> There's no particular reason I know of that means they couldn't be
> class decorators as well.
>
> That takes care of most of the configuration needed for the ZCA
> itself. How to deal with the rest probably gets more obvious once
> we've done this.
>
> //Lennart
> _______________________________________________
> Zope-Dev maillist  -  Zope-Dev at zope.org
> https://mail.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists -
>  https://mail.zope.org/mailman/listinfo/zope-announce
>  https://mail.zope.org/mailman/listinfo/zope )
>