The attribute variable called self.context in Adapters refers to the object instance being adapted.  Generally, self implements an instance of what it is being adapted to, although self may be a factory instead.

Since grok.View is an adapter, and forms are specialisations of grok.View, form view objects have a self.context. referring to the data for the view. 

The grok.context(cls) directive configures a grok.view (or adapter) to adapt objects of the type cls.

If this sounds strange, hang in there and all will be made clear.

Persistent Store

The ZODB (Zope Object Database)  is a persistent store of pickled python objects.  This store is hierarchical, having a root to the tree, and each component in the tree potentially containing other persistent components.

Traversal is a way of mapping a URL to a specific resource in this hierarchy.  As one would traverse the path in a file system by visiting each node in turn, one may intrepret a URL in the same way to eventually reach a specific resource (or object) in the ZODB hierarchy.  A data object identified in this way may be processed by one or more views, and is said to form the Context for the view or views.

It must be repeated here that traversal can also traverse attributes, objects in other databases, or even through objects which don't persist at all.

So, in the documentation for the ZTK or Grok, whenever one finds a reference to a context in the definition of views, adapters and other classes,  the context is invariably a data object against which an operation, such as view or form generation is being performed.

For example, consider the following URL's

/people/bob/show
/people/joe/show
/people/sue/show

Here, bob, joe and sue refer to data objects which might perhaps all conform to an interface IPERSON.  The 'show' operation is implemented as a view which expects its context to be instances of IPERSON, and produces HTML to describe the person, whether that person be bob, joe or sue.

The grok.context directive

In the Bluebream platform, the views defined against a given context would need to be configured for a site using the ZCML markup language. For example:

<browser:page
  name="helloworld.html"
  for="zope.site.interfaces.IFolder"
  template="helloworld.pt"
  permission="zope.Public"
  />

The above ZCML might be used to describe and configure the following view:

from zope.formlib import form
from zope.formlib import DisplayForm
from zope.site.interfaces import IFolder

class HelloWorld(DisplayForm):

    form_fields = form.Fields(IHelloWorld)

    def subFolderIds(self):
        for name, subobj in self.context.items():
            if IFolder.providedBy(subobj):
                yield name

Grok, of course eliminates this need, and does so through use of the grok.context() directive, and some conventions:

class myModel(grok.Model):
    ...

class myView(grok.View):
    grok.context(myModel)
    ...

The use of implicit convention eliminates a lot of specification and improves readability.

By convention, the name of the view is the lower case class name, and the template will be the view name with the extention '.pt' or '.cpt'.  Default permission is public, unless another view in the module specifies a different permission, in which case an explicit grok.require('zope.Public') directive should be used.  Grok goes a bit further as well, by stating the convention that if the model is the only one defined in the source file, the views in the same source file are automatically configured for the defined model, and it is unnecessary to use an explicit grok.context(...) directive.

Where else are contexts used?

Typically, wherever adapters or multi-adapters occur, you will find a context.  Views are actually adapters, which are instantiated from a model instance and browser request, and export a render method which returns a result that may be adapted to an IResult interface.  The context here is the model which is being adapted.

Automatic form fields (formlib.field) are also models which likewise have views associated with them called widgets.  So widgets as produced by the formlib library also have contexts, and render HTML snippets.

Viewlets are also adapters which adapt a model, a request, a view and a viewlet manager.  They typically return snippets of HTML.

grok.JSON, grok.REST, grok.XMLRPX also all operate against a context.