[Grok-dev] Grok 1.0 final?

[Martijn Faassen]

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

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

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

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.

Regards,

Martijn