Martijn Faassen wrote:
Hey,
Martin Aspeli wrote: [snip]
- In ZCML (or a grok.require() directive) use the Zope 3 name
Grok also has a grok.Permission you can subclass, and those subclasses can also be passed to grok.require().
I know, but I kind of consider creating permissions by subclassing grok.Permission an anti-pattern. That is, I don't like the idea of using Python classes purely for declarative configuration. That's the kind of thing that ought to sit in a configuration file, IMHO, and ZCML works fine for that kind of thing. But I digress. ;)
- In code, e.g. when doing a checkPermission() call, use the Zope 2 name - With GenericSetup's rolemap.xml, use the Zope 2 name
We haven't gotten around to making grok.Permission subclasses useful here yet in Grok, but we should.
[various proposal]
Thoughts?
I'm +1 on this, though with the caveat that I'm quite far from Zope 2 right now so I don't have a full picture of the impact. But it looks like a good way to move Zope 2 closer to the Zope Toolkit approach.
Like I said, I think fixing it at the low level AccessControl API would be more invasive than I'd first thought. I'm not sure it's a safe thing to attempt right now... Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book