[Grok-dev] Re: On CMS's in Grok

[Martijn Faassen]

Andreas Jung wrote:
> --On 2. April 2008 20:32:47 +0200 Wichert Akkerman <wichert at wiggy.net> 
> wrote:
>>
>> How about we give people a challenge: grokify Plone. I don't mean port
>> Plone to zope3 and grok, but apply the concepts grok introduces to
>> Plone.

 > What does "grokify Plone" mean in detail?

A good line of questioning. :)

 > What are the part of Plone
 > that would benefit from using Grok approaches (benefit for the
 > application developer and for the Plone framework itself)?

I think Plone could potentially benefit from using Grok's approach to 
registration. In this, Grok would initially be simply a replacement of 
ZCML. Grok supplies a lot of facilities there already, and there's 
usually a fairly straightforward way to go from custom ZCML directive to 
custom Grokker.

This I think would make Plone more easy to develop with (i.e. more easy 
to extend), as things would be in one place instead of spread between a 
Python file and a ZCML file. If you want to add an adapter or viewlet or 
whatnot, you'd just have to edit a single file (and another one with a 
template if a template is involved).

That said, I suspect that for a framework with the complexity of Plone, 
the introduction of explicit interfaces that Five/Zope 3 introduced was 
a good thing, and the introduction of ZCML was at least not a bad thing. 
ZCML work better in Zope 2 than it does Zope 3. :) (in part because Five 
doesn't have content-level security proxies like Zope 3 - the 
declaration of security and the debugging of such can drag down 
development a lot).

That said, I think Plone could be made easier by letting people use 
existing grokkers and introduce a few new ones that help register Plone 
content types.

 > What would it mean for the Plone middleware?

What is the Plone middleware?

 > Which would be the impacts on the
 > component architecture and the old horse Zope 2?

I don't think there'll be much impact to both the component architecture 
or Zope 2. Grok would need to work in Zope 2, which is basically just a 
continuation of the Five project. I expect grokcore.component now works 
out of the box in Zope 2 already. Grok uses the same component 
architecture as Zope 3, so I see almost zero impact on that.

Regards,

Martijn