On Sun, Mar 20, 2011 at 11:00 AM, Hanno Schlichting <ha...@hannosch.eu> wrote:
> On Sun, Mar 20, 2011 at 3:28 PM, Jim Fulton <j...@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.


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 Fulton
Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope )

Reply via email to