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

[Jan-Wijbrand Kolman]

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('...')
> 
> 
> the newly created class is actually not an IPermission. Furthermore, 
> it's not an instance of *this* class that gets registered as an 
> IPermission utility, it's an instance of a completely separate class. So 
> the class I've created is a completely dead chicken. The same applies to 
> roles.
> 
> 
> Judging from the experience that I have with grok.GlobalUtility, but 
> also with any other elementary grok component, I would at least expect 
> to be able to exercise the IPermission interface (or IRole interface, 
> respectively):
> 
>   permission = MyPermission()
>   print permission.id
>   print permission.title
>   print permission.description
> 
> This brings us to how we can define permissions: we can simply fill out 
> the IPermission interface on the class:
> 
>   class MyPermission(grok.Permission):
>       id = 'grok.MyPermission'
>       title = 'My permission!'
>       description = '...'
> 
> 
> You might argue that we now no longer use the grok.name() etc. 
> directives. I don't consider this a disadvantage. After all, they're 
> supposed to be *extra hints* for the grokker to do creation and 
> registration. If the object already inherently contains this 
> information, I think it's much more valuable to have it with the object 
> in the manner that's meaningful and described by the object's API 
> (IPermission and IRole in this case).

This actually illustrates a principle that I try to tell people - e.g. 
my co-workers - when they're using Grok: "Never forget you're actually 
developing with Zope-3 and you're learning its API, where Grok makes 
certain things easier"

So, yes, this is valuable feedback and I wished we realized this 
earlier. I have only myself to blame for not looking a bit further into 
Zope's idea of permission objects and role objects (and not having 
looked at the other Grok components).

Since there's no released version of Grok with this feature I think we 
can change all we want in this regard.

I *hope* I can dedicated a bit of time next week to refactor, if noone 
else has the opportunity.

regards,
jw