[Zope3-dev] Configuration changes

[Jim Fulton]

Yesterday, Guido and I spent some time going over configuration
aspects of site development and he had a number of good ideas I'd like
to share and get feedback on.

Before I mention his ideas I'd like to note that the current UI is
definately too complicated. In many ways, it is a prototype designed
to work out some mechanism, much of which is needed to support
functionality, especially wrt installation, that isn't there yet.
In particular, there's a lot of mechanism to handle conflicting
configurations, which are needed to support software installation,
update, and uninstallation functionality as described in:

   http://dev.zope.org/Zope3/ThroughTheWebSiteDevelopment.

I believe that the UI can be greatly simplified without losing the
power of the underlying mechanism.

I'd also like to simply the task of writing local services and their
configurations.

Here are some of the ideas we came up with:

- Simplify configuration status. A configuration can be unregistered,
   registered, or active. Under normal situations, the "unregistered"
   state is uninteresting, so we can simplify this to just active and
   inactive (registered).

- Greatly simplify the "Services" view on the site/service manager.
   Now this view shows you the services configured and lets you access
   the service instances and configurations and lets you change which
   configurations are active. The UI is rather daunting.

   The services view should just show a list of the service types for
   which there are configurations.  For each service type, there
   should be a row of data:

   o A check box that is checked for active services and unchecked for
     inactive services.

   o The service name that is a link to the object providing the
     service. (This will not be a link if there are multiple
     services configurations and none of them are active.)

   o If there are multiple configurations for the service type, then a
     link will be provided to view all of the configurations for the
     service.

   o Perhaps the title of the service type definition will also be
     shown.

   A similar approach would be used for browsing other services.

- Greatly simplfy the configuration manager UI. This UI was designed
   to mimic ZCML files, but it doesn't scale very well. With only a few
   configurations, the UI can be overwhelming. This UI should show
   enough information to tell what the configuration is and provide a
   link to go manage it. It should also provide generic controls for
   removing configurations and for making several configurations active
   or inactive.

   Perhaps the UI should be a sequence of rows with:

   o A check box (for selecting rows for general operations)

   o Data. The data will be in two lines.

     The first line will contain a configuration status, type, and "key"
     data. This is data that defines what the configuration is for. For
     a service configuration, this would be a service type. For a page,
     this would be an interface, a view name, and a layer, if the layer
     is not the default layer.

     the second line woould contain configuration data, such as a
     component path or a permission.

     For example, for a service configuration, this might look like::

        Active Service ErrorReporting
        default/ErrorReportingService-1

     For a view configuration, this might be:

        Active Page index.html for IFolder
        default/index.pt, class default/index/IndexView, require Zope.View

     Perhaps the first line would be strong.

     When components or modules are mentioned, we should provide links
     to them.

   o A link to change the configuration.

Thoughts?

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (888) 344-4332            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org