[Grok-dev] Grok 1.0 final?

[Martin Aspeli]

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 
grokcore.*.

  - 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.

Martin

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