[Grok-dev] Neanderthal II possible sprint topics

Martijn Faassen faassen at startifact.com
Tue Sep 8 10:55:17 EDT 2009

Hi there,

I've written down some Neanderthal II sprint topics. Please discuss and 
add to this thread!


* We got to release Grok 1.0. I prefer to get that over with on day 1. A 
few people should review the issues and then release.


* I'd like to see people take the tutorials and documents on 
grok.zope.org and see whether they can't edit them to merge them into 
the official Grok documentation.

* New documentation would always be welcome. Identify holes in the 
current documentation (see recent mailing list thread by grokomobil!) 
and fill them up.

Dependency reduction

* Take the Grok trunk and make it work with a version of the ZTK

* think of a plan to manage the ZTK in the context of Grok. How can we 
help the ZTK project manage this so we can easily reuse the version listing?

* Once Grok is working with the ZTK, investigate the dependency 
structure of Grok and the grokcore.* and grokui.* packages. Try to cut 
away as manage packages as possible. z3c.recipe.depgraph is useful here.

* Coming from the other end: explore building a simple version of Grok 
that uses the grokcore.* libraries (without massive dependencies) and 
WSGI? What does this look like? What can Grok learn from this?


* What's necessary to make Grok with Python 2.6?

* five.grok: extracting more from Grok to make it easier to reuse Grok 
bits in other contexts, in particular Zope 2.


* Design how declarative attribute-level security declarations would 
look like in Grok

Templates & resources

* Merge new template registration branch into grokcore.view. We cleaned 
this up, this needs a final review and a merge.

* Investigate the use of hurry.resource as an official part of Grok 
proper. Also look at integrating z3c.hashedresource by default

* Explore an extension to Grok that uses hurry.custom for customizing 
static resources and certain kinds of templates TTW

* explore patterns for the use of client-side templates with Grok

* make it easier to provide custom JSON (de)serializers. I noticed it 
was harder than it should be to plug in datetime serialization code into 


A general theme might be looking at existing libraries in the Zope world 
and integrating them to be part of Grok by default. The role of 
grokcore.* is clean and small dependencies. Grok itself shouldn't be 
afraid of integrating useful libraries whre appropriate. hurry.resource 
and hurry.custom (see above) I'm biased about of course, as I wrote them 
myself. :)

Relational databases

* explore auto-generation of JSON from SQLAlchemy models

* look at formalchemy for producing forms from SQLAlchemy models

Planning the next sprint

I think the time between this Grok sprint and the last dedicated Grok 
sprint was rather long, even though we are most productive at such 
sprints. (we did have sprints surrounding conferences, but this is 
different). We should think about ways to make sprints happen more 

Any other ideas? Discussion?



More information about the Grok-dev mailing list