Move to Five/Zope3 Views (done)

We're rethinking the views a lot on the trunk, and although most of the results of that thinking will probably only land after 2.2 is released, here is the way we would like to go:

  1. Get rid of the views/ directory hierarchy with the edit/preview/public and then all the content types. This can be a lot simpler if we just start using Five/Zope3 views.
  2. There is a *lot* of view (helper) code in the content classes, which ideally should not have to know about views at all. We would like to move that code into view classes.

This would result in:

  • 'model' classes that are much smaller and cleaner, and contain  (almost?) no zope/view related hacks.
  • view classes that can be inherited from, so that the views for a specific content type only have to have code for view behavior specific to that type.

What is an open question to my mind is how to handle the templates: I really don't like macros, but I also don't know if there is a better way in zope 2/Five (or indeed in zope 3) to reuse/override parts of templates. If not we would have to keep macros working. *Additionally* we would like to be able to override/reuse parts of view templates from within the ZMI, basically in a similar way that site managers can do now. We want to discourage ZMI based development, but when it is needed, we want to make it as clean as possible, and as close to the way it would look on the file system, so that people can easily move stuff there when they want to.

Eric Casteleijn

Regarding discouraging ZMI-based development: it would be _very_ helpful to have a document giving a examples of a zmi-based development/extension for Silva and then showing how that would be done using z3 technology.  I, for one, don't really understand it yet, but my first thought would be to create a view on a "marker" interface, and then in the ZMI "Interfaces" tab attach that marker interface to the particular content object.  Even on the zope 3 web component development book I haven't seen a clear example of how to translate this type of Zope2 development to Zope3.

Andy Altepeter