Martijn Faassen wrote:
> Martin Aspeli wrote:
>> - 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]
> 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...
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -