History for ZopeMVCProposal

??changed:
-
*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":mailto:[email protected] 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