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. > 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. Hanno _______________________________________________ Zope-Dev maillist - Zope-Dev@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 )