[Grok-dev] Grok 1.0 final?
faassen at startifact.com
Tue Apr 14 12:54:53 EDT 2009
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
* 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).
> We are talking about integrating Grok (or grok approaches) into Plone 4
> and I am wondering how stable Grok is at this point.
Grok's APIs are pretty stable, I'd say.
martian is mature, though it has the subclass change coming (is in
trunk). Shouldn't break existing user code though, but it will impact
grokcore.component and other grokcore.* packages a bit.
grokcore.component is mature as well.
The other grokcore.* packages are mature as well in the sense that
they're almost a year old now as independent packages and are themselves
based on code we've been evolving forward since the beginning of Grok.
The main area we can improve things is making them depend on a lot less
Zope Toolkit code. This is mostly a Zope Toolkit issue. Grok 1.0 isn't
going to wait for all that to come through; that's a Grok 1.1 or Grok
I'll also note that Sylvain has been doing a lot of work making Silva
use Grok - you're not the first Zope 2 user of Grok.
Grok applications written in early 2007 work in a modern Grok with minor
modifications, even though Grok's implementation changed considerably
Eventually we'll move on to Grok 2.0 development. That should have a
radically smaller dependency list. We might also swap in chameleon as
the default template language, and hurry.resource for resource handling.
I hope zope.pipeline will also be ready by then. Perhaps adopt z3c.form
for form handling. But since Grok takes the "megaframework" approach
none of these should break the world.
More information about the Grok-dev