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 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )