[Grok-dev] Re: Grok in Zope 2: Paris Sprint first day wrap up:
faassen at startifact.com
Fri Apr 25 20:40:32 EDT 2008
Lennart Regebro wrote:
[success for grokcore.component]
> 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
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.
> 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:
> 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):
> 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.
More information about the Grok-dev