Configuring basic add/edit views for the ZMI

At the time of this writing, this is the farthest I've gotten with this experiment in Zope 3. What this file, browser.zcml does is wire up some basic views for the Todo List and Todo items. At this point, we have not written any HTML templates or any view controllers. At this stage, we don't really need to. This is all that is needed to use automatic add and edit forms, complete with code validation. The interfaces we defined go a long way to providing these forms with their display. We also define some containerViews for the Todo List. Since the TodoList subclasses and sub-interfaces a standard Zope 3 container implementation (think 'Folder', but much simpler. More like a dictionary), it would be nice to reuse the basic container views for the Todo List. This is how we'll get away with adding Todo items:

<configure xmlns="http://namespaces.zope.org/browser">
  <!-- Allow adding of the Todo List -->
  <addMenuItem
      class="todo.TodoList"
      title="Todo List"
      description="A Todo List"
      permission="zope.ManageContent"
      />

  <!-- Allow basic Zope 3 container views for the Todo List -->
  <containerViews
      for=".interfaces.ITodoList"
      index="zope.View"
      contents="zope.View"
      add="zope.ManageContent"
      />

  <!-- And now add / edit forms for the Todo list -->
  <addform
      label="Add Todo"
      name="addtodo.html"
      schema="todo.interfaces.ITodo"
      content_factory="todo.Todo"
      permission="zope.ManageContent"
      />
  <addMenuItem
      class="todo.Todo"
      title="Todo"
      description="A Todo Item"
      permission="zope.ManageContent"
      view="addtodo.html"
      />

  <editform
      schema="todo.interfaces.ITodo"
      for="todo.interfaces.ITodo"
      label="Edit Todo"
      name="edit.html"
      permission="zope.ManageContent"
      menu="zmi_views" title="Edit"
      />
</configure>

There is more that these ZCML declarations can do - filter out specific fields from a Schema definition, wire into custom classes that override widget definitions or provide other help, or use alternate templates than the ones the system uses. This allows the add/edit functionality to be used in custom applications that don't make use of the ZMI but could otherwise benefit by what these editform and addform view controllers provide.

Screen shots of the views generated by these declarations are in the extended entry.

Above we have the ZMI add lists. The first one shows the root list, including 'Todo List' and 'Todo', from the addMenuItem interfaces. The second one shows the add list from inside the 'Todo List', which is restricted to just Todo. This is from the ITodoList.__setitem__.precondition configuration.

This shows the automatically generated add form with an input error. You can also see the optional Object Name field which gives the object its identifier within its container. If not supplied, Zope 3 can choose the 'name' (equivalent to the Zope 2 'id').

This shows the todo list contents. One entry had a name manually entered by me, the other one was chosen by Zope 3. This is done via a Name Chooser component (interface INameChooser). In the future, I hope to look at how to write a custom name chooser that automatically generates the todo's name based on the main 'to do' item content. In effect, this should mean just writing an INameChooser adapter for ITodoList objects.