[Grok-dev] Neanderthal II possible sprint topics
faassen at startifact.com
Tue Sep 8 10:55:17 EDT 2009
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.
* 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
* 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