[Grok-dev] Grok 1.0 final?
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
> See here too:
> 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
- 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