Martian directives improvements (and introspector UI improvements)

When refactoring Grokkers during the Snow Sprint, I noticed some patterns in the ways various Grok class directives are used. A common pattern in particular is falling back on a default. Let's for example look at the following code:

class MyView(grok.View):
   grok.require('zope.Public')

This code is equivalent to this, as zope.Public is the default:

class MyView(grok.view):
   pass

Currently the grokkers that register this code handle this with code like this:

permission = class_annotation(view, 'grok.require', 'zope.Public')

The knowledge of how the default behavior works for directives is encapsulated in the grokkers, not in the directives. The new directive implementation instead allows you to do this to get at the right permission:

require_directive.get(view)

The require_directive has been set up so that it knows what the default is should the view have no explicit definition of default. In real-world code things will get more complicated - defaults might not be static but calculated, and dependent on which kind of class the directive is used on. I believe we can still encapsulate this in the new directive implementation. I expect the following advantages:

• the implementation of grokkers becomes shorter.
• grokkers will be easier to understand.
• grokkers will be easier to write.
• We will notice inconsistencies in the use of directives sooner. An inconsistency for instance is the use of grok.name(); it defaults to the class name for views, but for utilities it defaults to the empty string. This is likely an inconsistency we want to retain, but at least we'll not do this by accident so easily.
• we build important infrastructure for introspection. We want the introspector UI to tell the user which directives were used on a class, and also which defaults were assumed. The new directives should encapsulate this information so that the introspector UI can make use of this.

On the train trip back from the Snow Sprint I started sketching out the implementation of such declarative directives in Martian, for now in a new, unused, module called ndir.py and doctest called ndir.txt. See the code here.

At the sprint, if anyone is interested, we can hopefully push this implementation forward to a point where we can start using it in Grok. We can then also look into how we can use this code in the introspector UI.

Relational database integration

I already wrote much about this earlier this week. I think making relational database integration a first class citizen is a really important topic for Grok.

Improving KSS integration

KSS is a declarative framework for doing AJAX style UIs. With KSS there is no need to write Javascript unless you want to expand it with new plugins. KSS aims to make it very easy to write dynamic web applications. KSS, while independent from Zope, does come from nearby in our community - it originated in the Zope community, and some of the KSS core hackers are involved in Grok.

We built an rough integration of KSS into Grok at the Neanderthal sprint last october, and at the Snow Sprint this was improved somewhat. Now it will be time to polish this integration, making it work as easily as possible out of the box, so that people can run with it.

The aim here is that someone can sit down and read a simple tutorial and has their Grok application working with KSS within 10 minutes.

Improving WSGI integration

Grok has been speaking WSGI since last year now, but we want to make this integration there by default. We need to investigate how to easily enable WSGI middleware with Grok, and how we are going to change the default Grok deployment to make use of the WSGI infrastructure. We also should investigate some useful middleware components we may want to ship with Grok by default.

The aim is again polishing: we have the code, but it's only halfway done if someone cannot sit down and use it within a reasonable amount of time.

Menu infrastructure

One feature that Grok doesn't support easily yet is the dynamic generation of 'menus'. If I have an object that I want to show up in my navigation menu, I should be able to do so in a straightforward fashion. If I have different add views in my application that each create a type of object, I want to be able to generate a drop-down list of all add views available. As with everything in Zope 3 and Grok, it needs to be extensible: I should be able to write an extension to a core application that also adds its own entries to the menus defined in the core.

This is a design task first: identify the use cases and then think about some patterns in code that would fulfill them.

After that, set out to implement this. It may be that the viewlets support (in Grok trunk) will be helpful here as a foundation.