plone.app.controlpanel Package Readme
=====================================

Overview
--------

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 unconvential approach
as EditForm's only work on one single context, as they are targetted 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 adapater 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 baseclass
    '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 specifiy 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.
