Lots more is going on in the Grok world, so the Grok Status Update has received a part 3. See also part 1 and part 2. grok.OrderedContainer Thanks to work at the Grokkerdam sprint, Grok 0.13 will contain an
IOrderedContainer implementation besides the normal container:
grok.OrderedContainer. grok.Require We realized during the Grokkerdam sprint that we should allow the user
to pass the permission class directly to grok.require, instead of
having to pass the permission name. Using permission names is still
possible (and sometime necessary if the permission isn't defined by
Grok itself), but in Grok 0.13 it will also be possible to pass the
permission class directly: menus in Grok Jan-Wijbrand and myself discussed what menus in Grok could look like a
week or two ago. We found many parallels with viewlet managers (menu
itself) and viewlets (menu entries), and we think we can build this on
top of viewlets. We need to work out a more detailed design proposal
and discuss it on grok-dev next. grokcore.component release At the post-PyCon sprint, Brandon Craig Rhodes and Robert Marianski
worked on extracting generic bits from Grok into a separate package
called grokcore.component. At the Grokkerdam sprint, Philipp von
Weitershausen polished it off, merged the branch that makes the Grok
trunk depend on it, and released it to PyPI. grokcore.component is compatible with Zope 3 and also with Zope 2.
It is more light-weight than Grok itself, so it's easier to integrate
in existing projects. Various Zope 3 and Zope 2 developers have
started using this package in their own projects. five.grok At the Paris Plone sprint, held in the week before the Grokkerdam
sprint, a new package five.grok was created. This package aims to
provide Grok functionality to Zope 2. It builds on
grokcore.component, and extends its functionality with other
things like view support. During the Grokkerdam sprint Eric Casteleijn
continued work on five.grok, adding tests and updating it as
grokcore.component itself was updated. The task is now to get a dedicated set of volunteers who want to bring
five.grok up to speed. The idea is that five.grok will as much
as possible make available Grok's APIs in Zope 2. It won't engage in
the invention of new APIs; that is for other packages which build on
this. directive refactoring A large project was completed at the Grokkerdam sprint by Philipp von
Weitershausen and Jan-Wijbrand Kolman. During the Snow sprint in
january, I noticed quite a bit of regularity in the way directives
were used in Grok. I figured there was a way to abstract this out and
push it into our Martian configuration library, so on the train trip
back from the Snow sprint, I started a project to implement this in
Martian. Philipp and Jan-Wijbrand extended this work at the Grokkerdam sprint,
started using it in grokcore.component and Grok itself, cleaning
up Grok's grokkers quite a bit. At the end of the sprint we reviewed this work and started work on the
next step of this pattern: declare exactly what directives a grokker
uses in the Grokker. This cleans up the code even more, and should
make it much easier for the Grok introspector to deduce useful
information for the introspector UI. Philipp continued this work after the sprint. This is now merged into
the Grok trunk as well (and grokcore.component uses it too,
already released). Since then, we noticed another pattern in the way
classes were grokked that actually register the methods of these
classes. Philipp set out to work on this too, and this resulted in a
new part of Martian called the MethodGrokker, which codifies this
pattern. This further cleans up Grok. Since then, I've further extended Martian. It now has a nicer
tutorial, and it uses the new directive infrastructure to define
grokkers as well. This makes a grokker look like any grokked class -
it derives from a base class and has a few directives. All this work will land in Grok 0.13. CRUD Joachim Schmitz and myself worked on a demonstrator project to see
how we could construct a powerful CRUD framework on top of Grok,
automating the user interface. This is code that typically needs a lot
of pluggability, and pluggability is where the Zope component
architecture shines. Hopefully we'll see more progress on CRUD in Grok in the future. EuroPython Grok sprint We will be having another Grok sprint after EuroPython this year. We
are looking for people to participate. If you want to join in, please
add your name here:
![[Comments]](/blog-content//themes/Default/comments.png "3 comments")
(3) Wed Jun 11 2008 12:49 Grok Status Update part 3:
class MyPermission(grok.Permission):
grok.name("my.permission")
class MyView(grok.View):
grok.require(MyPermission)
- Comments:
Posted by Peter Bengtsson at Wed Jun 11 2008 15:42
Jan-Wijbrand helped me used the new martian directives in megrok.responseheaders. For what it's worth, checkout out this file for an example that defines two directives using the new martians. http://svn.zope.org/megrok.responseheaders/trunk/src/megrok/responseheaders/headers.py?rev=87144&view=autoHaving said that, I've heard (or misunderstand) that martian has changed again so I'm not sure it's such a great example anymore.
Posted by Martijn Faassen at Wed Jun 11 2008 17:02
Peter, I think that code should continue to work unchanged, as it doesn't use any grokkers. Only code that defines grokkers (in a meta.py, for instance) will be affected.
Posted by Noah Gift at Thu Jun 12 2008 04:20
Very cool to hear about a Grok CRUD framework. Would love to see more about it. I could really use something like this at my current company! Keep up the good work.
