[Grok-dev] grok EuroPython tasks

Martijn Faassen faassen at startifact.com
Mon Jul 2 11:52:08 EDT 2007

Hi there,

First of all, if you're planning to come to the EuroPython grok sprint, 
please add yourself to the list of sprinters so we have an idea of who's 


I came up with a list of potential sprint tasks. Feel free to reply and 
note your interest, or alternatively, propose your own sprint tasks. 
Note that these tasks aren't *just* sprint tasks - feel free to take 
them up independently of EuroPython, but do let us know on the list that 
you're working on it.

switch to Zope 3.4 eggs

Philipp already did some of this work, but we need to finalize it and 
merge it into the trunk. Right now Grok still relies on Zope 3.3, but we 
want to switch to Zope 3.4 and eggs. This makes extending Grok with new 
packages easier (as these usually have 3.4 dependencies). This also 
needs changes to grokproject.

grokproject updates

We have had a lot of feedback on people not being able to install Grok 
in some circumstances. We need to take this feedback very seriously; for 
all the people who actually give us feedback there might be 10 who just 
tries this and give up without ever telling us.

Since we're going to make grok rely on eggs anyway which necessitates 
grokproject changes, we should give all these grokproject issues a good 
review and resolve them where possible. We also need to update the 
tutorial documentation.

eggified grok

Now that the martian work is complete, the time has arrived to split 
grok itself up into a core and various eggs. We will still have a 'grok' 
package with the same facilities as before, but much of the 
functionality is split out into separate 'grokcore' eggs. These eggs are 
usuable independently, meaning we can build proper Zope 3 extensions on 

configuration actions for grok

Grok needs to start using configuration actions, like ZCML does. This 
means researching which configuration actions we need to generate (by 
investigating what ZCML does) and modifying our code to generate them. 
This work is also necessary to make it possible to write proper Zope 3 
extensions that make use of Grok technology.

integrate paste stack into grok

Depending on how much we trust the maturity status of the Zope 3 paste 
integration, we can start integrating Philipp's "zope on a paste" stack 
to be the default for Grok. [Philipp is giving at talk about this at 

give grokstar an actual UI

Grokstar, the grok-based blogging application, actually has quite a bit 
of functionality. This functionality is very badly exposed to the world, 
however. A good task would be to give Grokstar a proper UI. This 
probably also means Grokstar needs to be extended with new features.

form handling patterns

One of the things I noticed is that 'update()' often fulfills two 
purposes - taking special actions if form parameters are filled in, or 
bailing out if not. Could we provide a bit of help here in the grok.View 
class to make this look cleaner?

admin UI work

The sprint is an excellent opportunity to work on the admin UI. We 
should definitely at least have a discussion session on the topic.

template language plugins

Explore the recent developments concerning Buffet/Smorgasbord and see 
whether we can make pluggable template languages work with Grok. There 
are lots of integration issues to discover and explore, so we should 
pick a concrete template language and see where we end up. I'd propose 
Genshi: how would Genshi be used in the context of Zope 3 and Grok? 
[There is a talk about Genshi at EuroPython]


Explore some of the theming options we discussed for Grok. 
Pipeline-style postprocessing, etc. Some of the Genshi work might be 
useful here too.



More information about the Grok-dev mailing list