[Grok-dev] Grok 1.0 final?

[Wichert Akkerman]

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

-1

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.

+1

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.

-- 
Wichert Akkerman <wichert at wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.