[Grok-dev] Re: Grok in Zope 2: Paris Sprint first day wrap up: Success! (Kinda)

[Martijn Faassen]

Hi there,

Lennart Regebro wrote:
[success for grokcore.component]

Great!

> Next we started looking into making a grokker for Views. Those needs
> security, so we are thinking we might start a grokcore.security
> module, with the security grokkers et al in it. Does that seem like a
> good idea?

With "security grokkers", you mean the grokkers for grok.Permission and 
grok.Role? I think the problem will be that these grokkers use Zope 3 
APIs that don't exist in Zope 2. When you actually *register* a view, 
you'll also have to use a different API than using a Zope 3 checker, I 
think.

I think you might be best off for now to create a bunch of new grokkers 
for Zope 2 that register permissions, role and views. At least the view 
grokker we should be able to refactor eventually so we have a common 
base to support both. I think it's a good idea to make it work before we 
look at what would be needed to refactor, though.

[snip]
> The fix for this is easy, but we want approval for it, before we do
> this change. And the change is that in martian.core, we add:
> 
> try:
>     from ExtensionClass import ExtensionClass
> except ImportError:
>     ExtensionClass = types.ClassType
> 
> and then change a line in MultiGrokker.grokkers from
>         if obj_type in (type, types.ClassType):
> to
>         if obj_type in (type, types.ClassType, ExtensionClass):
> 
> Stylistic variations of this is possible. :)
> What are the opinions on this?

I think this is fine, as long as Martian isn't going to rely on 
ExtensionClass in any real way upon normal installation. I imagine we'll 
see more of this kind of issue as we see more meta-classes, so it's 
probably a good idea to work out some more general approach eventually. 
That said, if we can get rid of this immediate problem with about 5 or 6 
lines we should do so.

Regards,

Martijn