[Grok-dev] Re: grok.Permission and grok.Role

[Martijn Faassen]

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.name('grok.MyPermission')
>       grok.title('My permission!')
>       grok.description('...')

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.

Regards,

Martijn