jcerjak / plone.app.controlpanel

Plone's "Site Setup" UI

Introduction

This package provides various control panels for Plone and some infrastrucuture to make it as easy as possible to create those with the help of zope.formlib.

The general approach taken is to re-use as much of formlib as possible. This lead to the decision to use formlib's EditForm's functionality, as these provide the most automation found in formlib today.

As a result of this decision we needed to take a slightly unconventional approach as EditForm's only work on one single context, as they are targeted at editing content objects, which usually are available as one context only.

Control panels on the other side most commonly present settings from various sources and group these in a user-friendly way. In order to still be able to use EditForm's we introduce one abstract adapter as a middleware layer per control panel, that is used as the one context formlib's EditForm's need but internally pulls in the various settings from all the possible sources and pushes them back to the right places again.

Following this approach a control panel consists of at least three classes:

• An interface that describes the settings to be available in the control panel with the help of zope.schema. This gives us automatic type checking and some other basic validation of the settings. It also lets us specify vocabularies to be used for Choice-type properties.

• An adapter implementing the above interface, exposing all the different settings as properties. As we don't want to have those control panels available all over the place, we restrict them to adapt the 'IPloneSiteRoot' only. Sometimes we use the 'SchemaAdapterBase' class from CMFDefault.formlib and the property wrapper 'ProxyFieldProperty' to automatically convert the values found in our site to the types expected by formlib and vica versa. For example we often need to store tuples while formlib expects sets, store encoded strings in site encoding rather than unicode or use Zope2's DateTime class instead of Python's datetime package.

• And finally the form itself. We can use the common base class 'ControlPanelForm' to provide us with a consistent look and feel for all control panels. This is accomplished by using the 'control-panel.pt' template. For most cases this should be the only template that needs to be written.

  The 'ControlPanelForm' also provides us with two common actions and as a side effect overrides the 'handle_edit_action' in a Zope2-compatible way, where the default implementation needs the current locale to be present as part of the REQUEST, which is not the case in a Zope2 environment so far.

  The form is also the place to specify custom widgets for some properties. There are some custom widgets available in the widgets.py module in this package.

While the above-mentioned works pretty well for simple cases it is not yet clear if it will work for complex control panels in the same way. Especially forms that use a multitude of actions (for example user/group management) or consist of more than one 'tab' (for example kupu but also smart folder settings) are not easily implemented so far.

Hopefully we will be able to provide common helper classes and templates for those complex cases as well, though.