Containment magic

First, I don't understand what you mean with "dummy" classes for each container. They're not dummy at all, they're in fact real, persistent containers that will be used (so they can't be dummies). I also don't understand what's wrong with the aspect of creating separate container classes for different types of containers. A "Department" container that contains Employee objects isn't the same as a "Company" container that contains department objects, for instance, mostly because you'd have different views registered for each.

As far as the convention goes, it is absolutely possible to have a container picked up as the default context, e.g.:

class Department(grok.Container): pass

class ListEmployees(grok.View): # automatically registered for the Department container.

Now, regarding your other complaint about the view being locked to the storage implementation: I think it makes for agility's sake to start out this way. But since Grok builds on Zope 3, it's absolutely possible to introduce interfaces and have views registered for those:

class Department(grok.Container): grok.implements(IDepartment)

class ListEmployees(grok.View): grok.context(IDepartment) # this view is now independent of the above implementation

I hope this clears up a few misunderstandings. I wonder what caused them in first place. Perhaps you can point us to places in the tutorial that appeared misleading?

After reading your reply, I took a closer look at the grokapps you added to SVN, the TodoList and the BookShelf -- from your code layout it gets rather obvious that the 'grok.context' by default is bound to the module itself -- just what i suggested in my post.

Searching the tutorial again, i found it described there too: "How does Grok know that a view belongs to a model? In the previous examples, Grok has made this association automatically. Grok could do this because there was only a single model defined in the module (Sample). In this case, Grok is clever enough to automatically associate all views defined elsewhere in the same module to the only model. Behind the scenes Grok made the model the context of the views."

If you infer from this that the 'context is bound to the only model defined in the module and you better use a module for each model' you are done. I admit i did not, but understand now.

So, i feel better now: views do not need to declare their context if defined in the same module with only one model existing.

I don't know if that binding still works if another model is imported into the module. If not, we are back to the start again.

And no, model classes that are imported from other modules are not taken into account when looking for possible contexts. That would be very confusing, wouldn't it.

Lastly, talking about the tutorial, I must admit that it still needs a lot of work. It only covers the very basics that you need in order to get started. So that's the excuse we currently have for why 95% of the tutorial talks about adding components to (not modifying!) the standard application class. As far as the "blurriness" of the other sections is concerned, I hope to receive more detailed feedback about what exactly is confusing in your opinion. Perhaps you'd like to join the grok-dev@zope.org list so we can discuss this?