Yesterday I returned from "Grok Sprint Zwei", the second grok sprint, hosted by Philipp von Weitershausen in Dresden, Germany (and partially at Gocept for the warming up). Grok is a project to make Zope 3 safe, easy and fun for cavemen and other hominids like ourselves. Zope 3 of course is the powerful and flexible framework for the construction of web applications. See here for my initial introduction of the Zope Grok project. To summarize, Grok is an advanced alternate way to construct Zope 3 based applications that makes it possible to use the powerful Zope 3 component architecture (the glue that binds Zope 3 together) without having to write lots of configuration code. Instead, we apply "convention over configuration" to Zope 3. We aim for two things: Besides a project, Grok is also a caveman. Here he is again, relaxing after his work at the sprint: We had five people participating in the sprint. Everybody present at the first sprint was back: Philipp von Weitershausen, Christian Theune, Wolfgang Schnerring and myself. New at this sprint was Jan-Wijbrand Kolman. Jan-Wijbrand and I go back a while by now; I've had the pleasure to work with him for some years. More recently, after the first Grok sprint, we have been doing regular work on Grok and Grok applications. I was particularly happy he could make it to the second sprint, as he has lots of experience with usability, and Grok is a (developer) usability project. The second Grok sprint was a success: we set ourselves goals and we accomplished them. We also played lots of Guitar Hero in the evening. :) The major new things in Grok after this sprint are: security declarations for views. Views are public by default but
you can now restrict access using permissions. This allows
Grok to make use of Zope 3's advanced authentication/authorization
support. In Grok, we deliberately turn off security for anything but
views (only security where your app faces
the web), as we noticed that the standard pervasive Zope 3
security proyxing model can hinder rapid application
development. local utility support. Local utilities can be used to do
context-specific configuration and storage (such as the storage
of an index). They are equivalent to CMF's tools. Utilities
are looked up by interface which makes it easy to plug in new
ones implementing the same interface. We now have an easy way
to use local utilities. Concretely, this means Grok applications can now easily use
powerful Zope 3 components such as the Zope 3 catalog for
indexing of objects. We think Grok now has enough features to start developing real world applications. We could of course only go so quickly as we're exposing existing Zope 3 features. Since we're now ready with features, what remains to be done? One thing we are going to continue to do is build real-world applications with Grok. This will help us polish Grok further. One of the main areas that is still lacking is documentation that tells you how to use Grok, so we will be working on this now. Another aspect we want to work on is a focused admin UI for Grok applications. This is explicitly much more narrowly targeted than the Zope Management Interface. The admin ui is aimed at developers and admins to install and inspect Grok-based applications. We hope to do an initial release of Grok within a few weeks. We are also planning another sprint in april, where we plan to make Grok ready to exit the cave and step into the wide world, club in hand and smile on his face - ready for the ascent.
![[Comments]](/blog-content//themes/Default/comments.png "8 comments")
(8) Tue Jan 09 2007 14:04 Grok Sprint Zwei: the Ascent of Man:
- Comments:
Posted by Jan-Wijbrand Kolman at Tue Jan 09 2007 14:32
My sprint report: http://jw.n--tree.net/blog/dev/python/second-grok-sprintThanks for the invitation!
Posted by Martijn Faassen at Tue Jan 09 2007 18:05
Great sprint report, JW! Thanks! Everybody who's interested in Grok should go read JW's report too.
Posted by Martijn Faassen at Tue Jan 09 2007 21:28
Philipp posted a blog entry with a complete Grok application in it: awesome!http://www.z3lab.org/sections/blogs/philipp-weitershausen/2007_01_09_you-thought-zope-3-wasn
Posted by Alec Munro at Tue Jan 09 2007 21:36
This is excellent. I've been hoping someone would do this so I didn't have to.I haven't played with it yet, but I've read everything I could find posted. From the little I've heard, interfaces aren't part of Grok. I wonder if someone could write something about this, because I happen to love interfaces, and I would like to understand more about how they would relate to Grok.
Posted by Alec Munro at Tue Jan 09 2007 22:06
Apparently I didn't read closely enough. The mammoth manager uses some kind of Interfaces.I think I'll be experimenting with this tonight.
Posted by Martijn Faassen at Wed Jan 10 2007 13:07
Grok fully supports interfaces; you can always pass an interface to grok.context. It's just that in some areas they're not *required*, such as when you just want to create a view for a content object. For utilities and adapters however you need an interface, as that's how they're looked up.
Posted by Kevin Smith at Thu Jan 11 2007 20:25
Looks great and has an enormous potential. It does a great job of crumbling the slabs of overly explicity zcml, but does it lean too far into RoR's magical convention over configuration fairy dust land? And Grok over dependent on ZPT?The trend these days seems to be templates are dumb and data is always pushed one way to the template. TurboGears does a nice job of being explicit with over burdensome in defining views. Here's a similar approach: @grok.view('index.html', zpt='path/to/template')
def index_html( self):
return self.dataAFAIK Phillip proposed something similarish at one point. I say all this, because I think the grok target audience is probably very similar to TurboGears/DJango/RoR audience. Ex-phpers and J2EE refugees, who are probably getting spoiled by the gluttoney of choices in templating languages available from things like Buffet and have never heard of zcml. Meanwhile everyone is trying to avoid SQL situps and trying to dress up their relational databasses like an object database. I think Grok's instincts can see through that.My two cents. Lose the dependence on ZPT and update "Grok smash zcml" to "Grok smash SQL!"Awesome work, looking forward to seeing more!Posted by Martijn Faassen at Fri Jan 12 2007 16:53
As to the dependency of ZPT first: I have the intention to investigate other template languages than supporting just ZPT for Grok eventually. I'm aware of Buffet. Integrating a new templating language has significant challenges though - not perhaps the basic use, but patterns of template reuse can be quite different so this requires careful thought. This is why we start with ZPT, which we know.Grok has support for template-push in with the update method on views:
def update(self):
self.my_pushed_data = 'something'
i.e. you assign to the view instance to push data into the template. The template can then access this using the 'view' object.I've been interested in pushing data into templates for a while now and have been considering other ways to expose views as a method instead of a class, along the lines you are suggesting.Having views be classes has significant advantages though - you can subclass for instance. We do support views-as-methods in Grok for the special case of XMLRPC support, where methods are turned into XMLRPC views. I'd be interested in exploring patterns for views as methods in Grok while supporting views as classes too. Important seems to me a supplying a straightforward refactor path from view method to view class.If you have ideas, perhaps join our grok-dev mailing list and start a discussion there. I might, soon. :)
