Hi, Not sure where to 'hook into' the discussion thread, so I'll just start here:
On 3/20/11 15:28 PM, Jim Fulton wrote: > Hm, it's been a while since I've looked at grok. Some notes: > > - The mechanism I'm thinking of should not require *any* ZCML. Do you mean "without having a configure.zcml trigger the scanning (a.k.a. grokking) process"? Or do you mean, "a mechanism that doesn't use configuration actions from zope.configuration"? If there's a different way to trigger the scanning process, that would be mostly fine for Grok. There's a couple of things actually configured thru ZCML files in some of the grokcore.* packages. I think they could be rewritten if necessary. ZCML files are as far as I can see not essential to Grok - they are surely not essential to martian (the scanning/grokking library used). > - 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. I have the feeling the "explicit versus implicit" part of the discussion has been somewhat mixed with the "to scan or not to scan" part of the discussion. Nothing in the martian library dictates "implicitness" as far as I can see. How Grok uses martian though, does have implicit, conventions-over-configuration design choices. Actually, these "conventions-over-configuration" choices are regularly discussed within the Grok community - some people (including myself) would like to see Grok not doing any "guessing" of configuration parameters during the grokking-phase of the application at all. Others disagree. As an example, there's the "megrok.strictrequire" package that, when included in a grok-based application, will raise grok errors when there are view components without an explicitly set permission requirement (where Grok normally would have used a conventional value). > - I'd prefer not to rely on subclassing, but I'm not dead set against it. For most components Grok relies on subclassing indeed. Note that registering global utilities, for example, can be done using module-level directives too, like can be done for adapters and subscriptions. > - Whataever we come up with has to work with Python 3, so > unfortunately, we can't use the syntactic trick of having a call in a > class like:: > > grokcore.component.implements(IContentProvider) Just to be sure: this is what is called "advice based syntax" or "in-class advice" right? Grok people call this a "directive". Anyway, as apparently this wouldn't work in Python 3 anymore, Grok should come up with an alternate spelling. Actually, people have already suggested to start using class decorators instead of in-class directives. Personally, I do not see an essential cosmetic difference between using a class decorator or a in-class directive. Like was said earlier in the thread: Grok had to use directives since there were no class decorators at that time. And what I have seen of Pyramid and venusian, the grok directives do mostly what the class decorators do: they leave information on the class in one way or another, that later is picked up in the scanning/grokking phase and used for registrations. Grok uses "grokkers" for that - "meta"-components that know how they can use the information left by the directives for making registrations (thru the zope.configuration configuration actions mechanism, which as a result plays nice with existing "pure zcml" registrations) What I know of venusian/Pyramid, is that the class decorators leave callbacks that will do the registrations in the scanning phase. Right? > The effort should certainly include an analysis of approaches like > grok. Maybe the mechanism should have the effect of enabling tools > like grok to be implemented more cleanly. I do not think the Grok project would be principally against this. regards, jw _______________________________________________ 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 )