[Grok-dev] Re: grokcore.component into plone
Philipp von Weitershausen
philipp at weitershausen.de
Fri May 16 13:15:06 EDT 2008
Lennart Regebro wrote:
> On Fri, May 16, 2008 at 12:30 PM, Godefroid Chapelle
> <gotcha at bubblenet.be> wrote:
> I still don't think that will be reusable for Zope2.
It depends on what grokcore.security is supposed to do. For now I think
it would only contain the grok.Permission and grok.Role base classes as
well as the grok.require() directive/decorator. These are not tied to
Zope 3. In fact, these are just *used* by grokkers which are indeed
Zope3- or Zope2-specific.
> Five's security implementation is very different from Zope3s. I think
> it is best to start implementing this, and see what, if any, gets
> reusable between versions.
Exactly. I understand that the driving factor would moving things out of
Grok is the reuse in Zope 2. However, I wouldn't want to create those
packages of outsourced materials just so that they fit Zope 2's purpose.
I think they should be packaged so that it makes sense for Grok and the
rest of Zope 3.
If this will just contain browser components (e.g. grok.View,
grok.ViewletManager, grok.Viewlet, etc.), I'd prefer calling this
grokcore.browser (which is more inline with Zope 3 naming conventions).
> That could work, if we make the baseclases pluggable, as Five uses
> different base classes from Zope3.
As I've said, I don't want to create reusable bits and pieces tailored
to Zope 2. If they're reusable in Zope 3, then that's good enough for
me. Then Five can worry about how to make it work in Zope 2. That's how
it's always been and it has worked well so far :).
Note that the baseclass issue is completely gone on the Zope 2 trunk
(yet another good reason for not butchering up Grok to make it fit Zope
2). The sooner we get to release that, the sooner this problem goes away
altogether. The only significant difference would be view security, but
we could probably create some hooks for that.
More information about the Grok-dev