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

[Darryl Cousins]

Hi,

On Fri, 2007-08-24 at 19:34 +0200, Jan-Wijbrand Kolman wrote:
> 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.

Just as another thought. In mars.template the components are named as
factories (TemplateFactory etc) to make it clear that the component is
*not* the template itself. As I read it the new Permission and Role
components are in effect factories, they `create` and `register` a
permission and a role respectively - in the same manner as the
mars.template factory-style components.

The current grok Permission and Role could be renamed as
PermissionFactory and RoleFactory without changing the functionality.

Best regards,
Darryl







> 
> regards,
> jw
> 
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> http://mail.zope.org/mailman/listinfo/grok-dev