[Grok-dev] Re: grok.Permission and grok.Role
faassen at startifact.com
Tue Aug 28 05:57:17 EDT 2007
Philipp von Weitershausen wrote:
> I apologize if this feedback comes a bit late, though I guess it's not
> too late to potentially change anything.
> In grok we use mostly use classes to define and register components. The
> class we create is the component and the fact that it inherits from a
> special base class gets it registered. If grok needs additional hints
> for the registration, we use directives a la grok.name().
> All this is violated by grok.Permission and grok.Role. When I create a
> new permission, like so,
> class MyPermission(grok.Permission):
> grok.title('My permission!')
Actually, grok.Indexes also don't use this pattern - you can't
instantiate the grok.Indexes class. In our discussions on skins and
layers we also proposed a grok.Skin which won't be that way either.
We are using classes in Grok to define a domain specific language. These
classes themselves are not really functional as classes. We can compare
with the use of zope.interface.Interface subclasses in Zope 3, where the
class statement doesn't define a class you can instantiate either.
I like the consistency of using the class statement with the grok
directives here. I don't think we should come up with too many different
patterns for our domain specific language, and try to use grok
directives where possible.
If we can come up with a design that results in an actually useful
permission object made from the class, then we can consider it, but we
shouldn't force ourselves through contortions just to make sure that we
create Zope 3 classes for everything we define in our application.
I don't see you argue on *how* you'd use this permission object and
exercise a permission interface. Is there any practical reason to make
grok.Permission fulfill the IPermission interface? If we can come up
with good practical use cases for doing it that way, it'd be stronger.
More information about the Grok-dev