[Grok-dev] Grok 1.0 final?
wichert at wiggy.net
Wed Apr 15 03:37:11 EDT 2009
Previously Martin Aspeli wrote:
> 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.
-0 see below.
> - 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
Plone should not invent its own API if it is just the same as the grok
one. It would be better if these grokcore.* APIs can become part of the
Zope Toolkit and grok and Plone can share its documentation.
For the same reason I would rather see that grok does not shadow
functions such as implements or adapts. I feel it is important that
people see that these are not grok concepts but Zope component features,
and the import should reflect that.
> - 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.
The current naming in grok has always been a big turnoff for me, and I
was sad to see it appear in plone dexterity as well. With namespaces and
eggs we already have too many directories, and this adds even more.
Wichert Akkerman <wichert at wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
More information about the Grok-dev