ZopeMVCProposal

*Watch it, when I am editing this page, I'll be saving often! I will probably not notice other edits on this page! Rather, email me your comments. --MartijnPieters*

Intro

This part always gets fleshed out last, dontyathink?

Goals

• Cleaner API
  • Reduce dependency on HTTP specifics
  • More powerful access to the Framework by applications build on Zope
  • Easier to document
• Ease of adding support for other protocols and presentations

Proposal

Model-View in Zope

First of all, I see no need for a separate Controller or Presenter class in Zope. As a control message from the browser to the server usually results in the View needing regenerating, an integrated View-Controller system would be more efficient. Also, the View returned is very often closely related to the Control message, like a response code from a WebDAV? DELETE action.

In Zope, there are different layers of Models and Views, where one View can serve as a Model for another View. This chain will always end in a Response from Zope, relevant to the Request. Right now, a stock Zope installation has two layers of presentation: The protocol layer (like HTTP, FTP, WebDAV? and XML-RPC), and then an optional management View. Further layers include the widgets like the <dtml-tree> tag.

Layers and Stages

This layered cake of Models and Views makes it possible to introduce Model-View to Zope in stages, where we start with the basic OFS objects (Folder, File, Image, etc.). Then we can move on to the protocol implementations. Each step we take more presentation logic out of the Models, and move those to the Views.

Management View

The management View of the OFS objects currently consists of a collection of methods on those objects themselves, their names often starting with manage_. They are solely designed to be viewed through a HTML browser, which connects to Zope via the HTTP protocol.

The methods should be moved to ManagementView objects, one for each type of OFS Model object. As these objects hold no state, only one ManagementView instance is needed for each Model class, and they are not Persistent. A OFS Model will have its ManagementView object associated with it via a manage class attribute. This goes somewhat against the principle of MVC design that a Model should not know about its Views, but it is the most efficient and effective way for Zope to detect that the management View should be presented.

The ManagementView objects will take care of all management related presentation and control messages from the user, where the underlying Model is manipulated using methods on that Model. The View knows what Model it should act upon via the aq_parent attribute. Also, permissions should be acquired this way.

This scheme will break current Zope applications that use the current manage_* methods for object manipulation. We will have to device a scheme for redirection to or proxying of the new methods on the new View objects. This could maybe include optional raising of exceptions when an old style method was used somewhere. In a future version of Zope these old style methods could be phased out.

The ManagementView class should use inheritance to reduce complexity, where the class hierarchy parallels that of the OFS Model objects.

Example

The Image class inherits from the File class, which in turn inherits (amongst others) from PropertyManager and RoleManager. The ImageManagementView class should therefor be based on the FileManagementView, which itself is based on the PropertyManagerManagementView and RoleManagerManagementView classes.

Image instances will have a property manage that will return the ImageManagementView object. When called, it will render the default management screen for the referred Image instance. All further management tasks and screens will be calls to methods of the ImageManagementView object.

The OFS objects only become Model objects when they are completely independant from protocol and presentation. This means that REQUEST and RESPONSE parameters to methods on these objects will have to be eliminated. All data taken from the REQUEST object by the method will have to be passed in explicitly.

The Protocol View

Right now, objects are published by calling methods on them, and returning the result of this call. For the different protocols Zope supports, various hacks have been added to alter the way objects are being called to adjust the behaviour of those objects. For FTP and WebDAV? methods have been added to the requisted objects to support those protocols.

With Model-View, we could just have the ORB return the requisted objects, and then have more intelligent protocol View objects act on these returned objects. This does mean that the Views will have to adjust to the different types of objects returned, by checking for class inheritence for example. But if the returned objects adhere more to the Model paradigm, the required information to generate the right view should be easier to obtain.

Future Directions

What more can we do, but is better for a later phase?

--MartijnPieters