[Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?

[Jim Fulton]

On Sun, Mar 20, 2011 at 11:00 AM, Hanno Schlichting <hanno at hannosch.eu> wrote:
> On Sun, Mar 20, 2011 at 3:28 PM, Jim Fulton <jim at zope.com> wrote:
>> - The mechanism shouldn't require something to "grok"/analyze the
>>  code.  The mechanism should be explicit. This is implied by
>>  "pythonic".  I remember Grok being more implicit than skimming the
>>  links above suggest. Perhaps Grok has has become more explicit than
>>  I remember.
>
> Both Grok and Pyramid (or martian and venusian really) do a scan of
> the code to find the registration hints.
>
> I think you cannot avoid this, if you want to support an explicit
> configuration phase. Otherwise the first import of a module could
> occur at any point at runtime and have a configuration side-effect
> like registering a new view. Personally I find the venusian approach
> pretty simple and explicit enough.

I disagree.  First, the notion that you'd import at run time is pretty odd,
unless you count start-up in "runtime".

Second, well, really, I'm not ready to give up on a straightforward
definition of wiring that doesn't rely on module scanning.


>
>> Note that the move from "advice-based" syntax to class decorators
>> provides a good opportunity to revisit how some of this works based
>> on experience using the ztk.
>
> Taking one of the examples of grokcore.component, I think there's a
> lot that can be made simpler:
>
> import grokcore.component
> from zope.i18n.interfaces import ITranslationDomain
>
> class HelloWorldTranslationDomain(grokcore.component.GlobalUtility):
>    grokcore.component.implements(ITranslationDomain)
>    grokcore.component.name('helloworld')
>
> Based on my Pyramid exposure, I'd write this as something like:
>
> from something import utility
> from zope.i18n.interfaces import ITranslationDomain
>
> @utility(ITranslationDomain, name='helloworld')
> class HelloWorldTranslationDomain(object):
>    pass
>
> This does mean hardcoding default values into the registration calls.
> I'm not sure I see the value of avoiding this, as long as there's a
> way to unregister this utility and re-register the class with other
> values.

Yup.

Also, If there's an existing mechanism that does what I want and I'm
just ignorant of, I'd be happy to learn about it.  If such a thing
exists or can be cobbled together from existing ideas, I'd like to
elevate it either as part of the ZCA or as a best-practice tool that
stands independent of any particular application framework.

Jim

-- 
Jim Fulton
http://www.linkedin.com/in/jimfulton