[Grok-dev] Re: grokcore.component into plone

Godefroid Chapelle gotcha at bubblenet.be
Sat May 17 10:47:46 EDT 2008

Philipp von Weitershausen wrote:
> Lennart Regebro wrote:
>> On Fri, May 16, 2008 at 12:30 PM, Godefroid Chapelle
>> <gotcha at bubblenet.be> wrote:
>>> grokcore.security
>> 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.

Thanks for expressing my thoughts, I am still too bad with writing.
>> 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.


>>> grokcore.view
> 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 :).

But again we could share directive even if we cannot share base classes.
> 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.

Fair enough, nevertheless, I'd like to use those components before Zope 
2.12 gets relased. Actually, as with grokcore.component, we could use 
five.grok right now with 2.10

Godefroid Chapelle (aka __gotcha) http://bubblenet.be

More information about the Grok-dev mailing list