Grok Status Update part 3
Grok Status Update part 3
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:
class MyPermission(grok.Permission): grok.name("my.permission") class MyView(grok.View): grok.require(MyPermission)
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
Comments powered by Disqus