Customizing Five views in CMF ============================= :Author: Philipp von Weitershausen, philikon@philikon.de :Status: IsDraftProposal :Date: $Date$ :Original: $URL$ Status quo ---------- CMF ~~~ In the CMF, views are persistently located below the ``portal_skins`` tool. This is a folderish object containing sub-"folders". These sub-"folders" are actually *skin layers* containing views (Python scripts, Page Templates, DTML methods, etc.). Depending on the order these skin layers are aggregated to a *skin*, a particular view from a skin layer is found. Typically, every CMF-based product introduces its own skin layer because a) there's no "default" layer that it could install itself into and b) it is difficult to impossible to share a skin layer among several filesystem-based products. Customization of views happens by creating a copy of the original Page Template, Python script, or DTML method object in a different skin layer folder. This copy would be modified according the customization needs. Then the skin layer holding the customized view objects is registered as a layer of the skin *before* the layer that hold the original objects. In short, view customization in CMF happens on a new skin layer. Zope 3 ~~~~~~ Zope 3 views are typicall written on the filesystem as Python classes. If there's just a Page Template, the ZCML machinery which is used to register views creates a class on the fly and registers that. Views registered through ZCML are available *globally* which means they're always available. If no other skin layer is given, the view is registered for the ``default`` layer, a layer that should be a part of all skins. Views can be overridden in three ways: a) By registering another view on a different layer and making that layer a higher priority in the skin. b) By using ZCML overrides to replace the registration of a global view with another one in ZCML. c) By defining a local view. Local views are persistent and live inside local site managers. More local views override less local or global views. In practice, layers are typically used for overriding views that belong to the look and feel of a skin (e.g. Page Template macro views like ``standard_macros``) while ZCML overrides are better suited when overriding object views. It seems that the functionality for local views, at least Page Template-based ones, is available but rarely used. Problem ------- With the Goldegg project, the CMF and Plone codebase is starting to be "fivified." That means, certain functionality is rewritten using Zope 3 technology which is exposed to Zope 2 through the Five product. A particular low hanging fruit in this process have been browser views. Zope-3-style browser views easily allow you to factor out view logic into a compact class while an accompanying Page Template only takes care of rendering the HTML markup. Apart from being more Pythonic (after all, it's just a normal class), browser view classes also offer other advantages, for example better opportunities for optimization (trusted vs. untrusted code, caching, etc.). Being filesystem-based, they have one fundamental flaw, however. They don't allow easy through-the-web (TTW) customization, something which is supported by "views" living in CMF's ``portal_skins`` tool. Deployers of CMF and Plone-based systems are quite used to this feature and use it often; they would rather not give it up. General goals ------------- * We want to implement browser views with Five. That means Zope-3-style browser view classes, registered through ZCML. * We want to retain easy through-the-web customization. That means a customization should only be a couple of mouse clicks away, no filesystem access should be required. * We want to leverage the Zope 3 Component Architecture as much as possible. * A potential solution should be low on requirements. It would preferably work with Zope 2.8, Five 1.2 and CMF 1.6. Proposal -------- Tres on local views in the CMF http://codespeak.net/pipermail/z3-five/2005q3/000738.html persistent view/adapter registry (cmfviews) gets hold of views cmfsite/++etc++site is cmf site manager, takes care of persistent utility lookup (=> portal tools and zope3-style local utilities) as well as local view/adapter look-up PageTemplate-based views ~~~~~~~~~~~~~~~~~~~~~~~~ XXX Python-only views ~~~~~~~~~~~~~~~~~ XXX View objects with an API ~~~~~~~~~~~~~~~~~~~~~~~~ XXX Implementation status --------------------- None so far, still in editing mode.