[Grok-dev] Grok 1.0 final?

Martin Aspeli optilude+lists at gmail.com
Tue Apr 14 22:21:34 EDT 2009

Martijn Faassen wrote:
> Hey Hanno!
> Hanno Schlichting wrote:
>> I'm new to Grok ;)
>> Is there any page or tracker that lists what is missing for a 1.0 final
>> release?
> https://launchpad.net/grok
> See here too:
> http://grok.zope.org/project
> The main topics off the top of my head are:
> * finishing up the paster/WSGI story. This is a matter of feedback and 
> continuous improvement.
> * integrating a change in martian that allows Grok to better understand 
> subclasses, especially in the area of views. Martian has the code 
> already, but we need to go through the various grok packages.
> * we will likely break out grok.CodeView out of grok.View, separating 
> template-based views from python-code based views as it will allow us to 
> simplify some code quite a lot (and make view inheritance work, which 
> has been driving the martian changes).

Can you elaborate on this? What does the subclassing support do?

Having used five.grok a fair bit recently (and liking it!), and having 
thought about Plone's API story going forward, I think a possible 
scenario is:

  - Plone will ship with a number of "API" packages that basically 
contain grokkers and convenience imports (only - no implementation of 
actual functionality), grouped into a few different packages.

  - We probably won't encourage using grokcore.* or five.* directly, if 
only to give us a bit more control over the API and its documentation. 
However, I expect that the Plone API packages will mostly just facade 

  - We probably want a simpler view story. The CodeView stuff looks 
good. We definitely want Chameleon. Also, we may want a different 
template lookup convention: having <module>_templates/*.pt match view 
classes means we end up with a lot of files called 'view.pt' and lots of 
directories containing only this one file. I think we may prefer to 
switch this around, e.g. so we have templates/<context>_view.pt or 
similar. I'm not quite sure yet.

  - Zope 2 and Zope 3 have different conventions for traversing to the 
++resource++ namespace. I like the 'static' pattern, but we may want to 
look at the implementation behind it.

I've found grokcore.view a bit difficult to work with, because of the 
number of indirections going on with templates. If any refactoring of 
this is on the cards, it'd be good to know.


Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

More information about the Grok-dev mailing list