Some core Grok concepts

• DRY: Don't repeat yourself. By not needing to add code to lots of files, you save time and errors.
• Convention over configuration: sensible defaults. You can more easily look at other people's code and still understand where everything is.
• We have "grokkers" that deduce declarations from python code. So hardly any zope 3 configuration (zcml) is necessary.

Grokking

Grokking is triggered from zcml, with the grok directive. This should be the only zcml that is needed. It scans modules in your code for classes that subclass grok's base classes. Grok then registers these components with the Zope Component Architecture (ZCA).

If you follow standard patterns, you can leave out grok directives (grok.name, grok.require, etc) from your code, but if you need more control, you can use them.

Storage

grok.Model is usually your base class. Very light weight. It should be contained in a class with grok.Container as base class. There is no ordered container class yet; we will add it to the todo list of the sprint.

Traversal

Traversal in Grok is very easy. There is of course the default traversal that just works. But if you need more control, you add a traverse method to your model. This can instantiate virtual objects on the fly.

You can also use grok.Traverser to implement custom behaviour for someone else's context.

Sites

Sites is Zope 3 is a place to store local utilities and tools. Grok has grok.Site for this. As todo we may want to add locally defined views and adapters. And having non-persistent local utilities would be useful as well. And we want to be able to install local utilities in an existing site, instead of only in a new site, without hairy upgrade code.

grok.Application is a special kind of grok.Site.

Todo: look at GenericSetup to make upgrades easier.

grok.Indexes makes working with the catalog easier. Todo: upgrading indexes in an existing site should be possible.

Components

grokcore.component has several components you can use, also in plain Zope 3:

• grok.Adapter
• grok.GlobalUtility for looking up e.g. the global email sending utility.
• grok.MultiAdapter if you need to adapt more than just one context (for which you would use grok.Context. Not used a lot currently.
• @grok.subscribe is a decorator for subscribing to zope 3 events

Todo: set up caching for views.

Miscellaneous other utilities

Using persistance:

• grok.LocalUtility
• grok.Annotation: you don't need to mess around with own generated keys anymore.

Views

• grok.View: the most magic of the grok base classes, as we wanted to make this really simple. There is the url method which you can give some parameters (optional context and optional string for an alternative view). Todo: explore keyword arguments for these parameters. And explore improving flash messages (compare with Plone portal status message), which does not always show in combination with redirection.
• grok.Skin: this is just a name and a single layer (grok.Layer) that is associated with it. grok.Layer is just an interface; you can use inheritance to combine layers. Todo: more skin based control of what views exist. From a security perspective it is not nice that anyone can just add e.g. @@contents and see the ZMI. We need to make that easy (grokking it).
• grok.GrokTemplate: ugly name, needs more implementation. Some integration to use e.g. Genshi instead of Zope page templates. Todo: write Jinja (from Django) integration and other template languages.
• grok.ViewletManager, grok.Viewlet: You register viewlets (html snippets) for a viewlet manager. In zope 3 you need to do quite a bit of stuff to set up viewlets and viewlet managers. Grok of course makes that easier. Having viewlets available at a specific url is good for caching; the Lovely guys have done something for this. Todo: look at z3c.traverser for maybe making that easier and default. KSS (or any Ajax) likes viewlets. Todo: viewlet documentation.

Alternative views

• grok.XMLRPC
• grok.REST
• grok.RESTProtocol
• grok.JSON

Security

Security is all view related.

• grok.Permission is used to define permissions. The grok.require directive is used to require a permission. Todo: see if we can refer to classes instead of strings in grok.require.
• Todo: default authentication UI. With Zope 2 you have the acl_users. With Grok we currently ask people to roll their own code. There is a good base in Zope 3 to use.
• Todo: authorization APIs.
• Todo: model-level security instead of only on views. You can give local permissions. But security checks are currently only be done on views. We threw the object checks out as it is a pain to work with, but we can look into making this easier. The zope security is very powerful.

Formlib

zope.formlib based forms.

• Use grok.Form as base.
• grok.EditForm uses the schema of your class. The standard template is pretty ugly though and does not integrate nicely with your UI. Todo: better templates for forms. Viewlets might be handy here.
• grok.DisplayForm just displays stuff.
• Todo: z3c.form support. Perfect candidate for making easier by grokking it.

That concludes the component tour.

What else?

Grok is more than just the API. It is a sort of language with base classes, decorators, methods. It is an attitude to be friendly to beginners.

We want smooth installation for Grok.

• Goal: smooth installation for Grok and Grok applications.
• We maintain a list of versions of libraries we use: pinned versions. That works for core Grok. But it did not work for megrok.form recently. Todo: update to the Zope 3 KGS list of versions (from Stephan Richter). All tests in the KGS pass; with the Grok version list the Grok tests pass, but the other tests did not all pass. That is not good.
• Todo: downloads sometimes fail. Sourceforge sometimes moves stuff around, the cheeseshop can be down, zope.org can be down. Todo: look at zc.sourcerelease to make one tarball of Grok.
• Todo: version pinning for extensions. buildout.cfg may or may not be better than setup.py for this.

Relation database integration

• This should be a first-class citizen in the zope world.
• Todo: figure out default story for RDB integration. This can be a big discussion/fight about what we choose.
• Todo: auto generation of Zope 3 schemas from database table schemas. Often you will find you are repeating yourself here.
• Todo: Model and Container base classes for RDB. So these would not have persistence as they are not stored in the ZODB.
• Todo: patterns for security integration. You need a bit too much methods currently.
• Todo: obviously add documentation.

WSGI

Web Services Gateway Integration. We have code for this, but we need to make this easier; possibly put it in grokproject by default.

• Todo: check the differences between grokproject and zopeproject; there should not be much differences.
• Todo: make grokproject really available as a paster template. It can be done already, but we need to document this.
• Todo: put in a few useful WSGI components for development. Look at repoze too.
• Todo: development and deployment profile.

Menus

Actions, drop-down lists, navigation, things like that. An extension should be able to add to a menu. We can have grok.Menu, grok.MenuItem. Also see grok.Title and grok.Description, perhaps later grok.Icon.

• Todo: examine zope 3 menu directive approach and compare it with viewlets. Investigate what is there, also in Plone.

AJAX

• Todo: finalize KSS integration.

Resources

• Todo: consider what is the right way for Grok to do this.
• Todo: think about making it possible to overwrite static resources in extensions.

Introspector

• Uli has done work here and will be working on it for Google Summer of Code.
• Todo: improve the object browser UI. Show which defaults are used for directives that are not explicitly in the code. In Firebug you can see the calculated style; something like that would be useful.
• Todo: new directive implementation in Martian. grok.name has different defaults depending on where it is called. We can make that more explicit, guard against unforeseen uses.

Miscellaneous

• Back to the future: through the web (TTW) development. This made Zope 2 popular. We can look at five.customerize for overriding views. Defining a schema TTW would be cool, if we can avoid the problems from ZClasses.
• Make CRUD UIs TTW.

Documentation

• We have the beginner's tutorial. It gets you started, but it can be longer. This is maintained in subversion. For other documentation: just add it to the website and publish it.
• We have developer's notes in subversion.
• Todo: The Reference.
• Todo: website improvements. I could not update the link and text in the sidebar. This was hardcoded. Kevin Teague has done a lot of work here, but we need more people here.

Rule: a sprint project is not finished without documentation!

Update

Daniel Nouri pointed me to the setuptools docs that explain what is going on; plus the docs for disutils, especially the part about adding a manifest file. And Andreas Zeidler pointed to a thread on the Plone developers list. And Florian Schulze pointed me to both. :-) I have the feeling there are a few people reading this weblog. :-) Thanks everyone!

In my case the tar ball problems pointed out by Florian did not affect me. In fact, when I uploaded just the tar ball and tried to easy_install it, this went fine: an egg was automatically created from the tar ball. But it is good to know that there can be problems in that area too.

Conclusion for me: easiest is just to create and upload an egg from a subversion checkout, not from an export. And if you want more control, read those setuptools docs.