Not sure where to 'hook into' the discussion thread, so I'll just start
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
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
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
> - 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::
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.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -