ZopeMVC

Here I'll be keeping my thoughts and notes on ZoPe? and ModelViewController.

24/02/2000 I'll now start to work on a ZopeMVCProposal.

Thoughts

• We want to avoid having a View for every Model (basic framework object) in Zope: Some form of AbstractView?
• It should be possible for Products to add a View to an existing Model.

I think the this is related to the interfaces proposal that Michel will be making later this week. As seen in the PTK, we at Digital Creations are close to coming up with a way to specifiy interfaces. We will then start documenting the interfaces. More thoughts over at MVCAndInterfaces. --Paul

• Squeak (a OSS SmallTalk implemenantation), talks about Pluggable Views, and how it cleaned up their class hierarchy tremendously:

  """A pluggable view has a set of selectors that parameterize its model interface in such a way that instances of the same view class can be used on many different models. This simplifies and factors the system -- we were able to reclaim about 50 classes (!) from the old MVC system in the course of this rewrite."""

  From the README (http://isgwww.cs.uni-magdeburg.de/~raab/squeak/image/2.7/ReadMe.txt). Investigate this.

  Just noticed, the Object Arts article on Model-View-Presenter also talks about pluggable views: http://www.object-arts.com/EducationCentre/Overviews/ModelViewPresenter.htm

• 'nother URL that claims more flexibility. May be too complex, I scanned it over quickly: http://www.ibm.com/java/education/mvp.html
• Views could be subobjects of the Model. Different protocols and applications then can find the view they need.
  • So the management view could be modelURL/manage. Further management view URLs? would be rooted at that URL: modelURL/manage/editProperties.
  • ZopeStudio RDF could be modelURL/MozRDF

    *Bobo used to (and may still, but I doubt it. I don't think Jim liked this too much) use the method asHTML() on an object as a default HTML view if it had it. the concepts of asRDF or asMozRDF could be easily applied. However, if Zope had categories similar to objective-c, this would be even easier (categories in objective-c are a fairly clean way of extending base classes outside of the class definition itself. A RenderXUL category could define new asXUL() methods on core base classes in Zope without Zope needing to be extended itself. Python sortof allows this, but not as cleanly.) This may be similar to pluggable views.*

  Above scheme is not backwards compatible with the current management interface. Provisions for this? Maybe detect manage_* method calls and look for them on the manage View object?

Yes - one of the core questions for us to resolve is: how does MV(C) impact our core concept of "direct object publishing"? Can the two coexist? There are a lot of interesting arguments in the future over this I suspect :^) --Brian

• Currently, stock Zope objects like Folder and Image are based on base classes like ObjectManager, SimpleItem and PropertySheet. These base classes provide their own management screens. The base classes have to obe split into base Models and Views. The Folder Model can then inherit from the ObjectManager, SimpleItem and PropertySheet Models, and the Folder management View can inherit from the ObjectManager, SimpleItem and PropertySheet Views. This leads partway to the AbstractView.
• Of course, not all Views are URL based. XML-RPC, WebDAV and FTP could be handled by ZPublisher. This should make it easier to add specific support for these protocols to new products. Also new protocols (think SOAP) should be easier to add.

I disagree a bit with this. I'm becoming more and more convinced that protocols are probably views or at least some combination of a view and an "interface". I haven't had much time to ponder the relationship between the concept of view and interface, but I get the feeling that we will need to work this out before its all over.

Mostly, I think that the ORB (ZPublisher) should be as totally independent of protocol (view) specific knowledge as possible. This is not the case now, and some of the HTTP-centric behavior of the current ORB has made some funny workarounds necessary for at least the DAV and ftp protocols. --Brian

Hmmmmm. So the HTTP view should only use the ORB to retrieve the object, and then apply it's HTTP View to it. FTP and WebDAV? do the same. Management and RDF interfaces are Models that themselves are a View into the underlying Model. Kewl. FTPing? of RDF data =) The RDF Model/View could then update the underlying Model when you upload new RDF.

from jeffrey :: yessssssssss!!!!!! being too tied to HTML == bad, likewise with HTTP

by the way: you can do good now just by employing good programming practices. ie, on an event item class, we had two methods on the base class, editEventItem and manage_editEventItem. editEventItem had the full signature but is oblivious to REQUEST. And it called special setter methods for all the mass properties that it updated. manage_editEventItem had only REQUEST in its signature, used values out of REQUEST to pass to editEventItem, and return an HTML result. This works out fairly well. Not a major abstraction, but one that works now and can easily support new views in the future. And it works well with XML-RPC too since editEventItem doesn't return HTML.

How far will this go? Zope 3? --MartijnPieters

• As the major protocols supported by Zope are all connectionless, no updates from Model to View are needed (or possible). Views update themselves by requiring the Model.
• Blue sky: If models update their associated views ( if they so desire), we could also support statefull protocols. You could hook a native GUI to Zope that gets automatically updated when others (using any kind of access to Zope) make changes. Updates can be realised if we add a simple Observers architecture to Models. Observers register themselves with the Model, and every time the Model changes the registered Observers get notified of the change (which might be qualified).
• Adding Observers would enable Views to employ caching of Model data. Also, Observers are widely usable in Zope outside of MVC.

Raking up things a little more: apart from the protocol question, there is also the point of monolithic views of documents: we have roles in Zope and we have permissions. The main point with editing Zope was always the dichotomy between rendered and not rendered. IMHO rendered or non- rendered views (or partially rendered views of objects) should be context dependent: some roles may edit more/other dtml tags then others. Plain content (HTML/XML/whatever in a current dtml document) is always editable, dtml content would depend on the permissions/roles of a user. Not sure whether this belongs here - just kicking it in once more.

-- Rik

This could be handled by a View that presents the Model with added Metadata on security. --MartijnPieters

• On AbstractViews?: The idea is to enable a View to be able to modify an Model even if it doesn't know anything about that Model. There should be an interface that'll let the View query the Model for it's default interfaces. I am thinking along the lines of a structure, for example:

  {'id': {'readonly': 1, 'getter': id, 'type': 'string'}, 'title': {'readonly': 0, 'getter': title, 'setter': setTitle, 'type': 'string'}}

  or some such structure. It will allow a View to build a minimal interface for objects unknown to it.

  Hmmmmmmm This might interfere with Security, or at least with the filtering of Views. An AbstractView will have to find out what properties are visible/changeable by the current "Viewer".

  A HMMMMmmmmMmMmMMM? from Jeffrey (Shell) This is actually kindof how PropertyManager works.

• On Model-View and Model-View-Controller (or -Presenter, or any further elaboration of the paradigm): I see no need for anything but Models and Views in Zope. Any change to the Model results (up until now anyway) in the View being regenerated from scratch. Controllers can take care of that much better if they have been interated into the Views.

  I might be utterly wrong here on the subject of for example the protocol level. A REQUEST could be a Controller related thingy, and a RESPONSE is (part of/generated by) the View.

This document changes rapidly. Sorry if I overwrite your additions! --MartijnPieters