#33: New Customization Policy implementation

Contents

1. Motivation
2. Proposal
3. Implementation

Proposed by

mrtopf

Proposal type

State

rejected

Motivation

CustomizationPolicies right now are just a set of functions to be called. This makes it hard for a site administrator to know what actually is going on and what ConfigurationMethod is doing what. A need of categorization would make things easier. Moreover all ConfigurationMethods are called right now in the default Policy. This makes it impossible to create new ones. In order to make this better, ConfigurationMethods will be modeled as classes which also hold some description about what they do.

A goal still outside the scope of this PLIP is to obtain the manual made configuration of a site and put it into a CustomizationPolicy.

Proposal

The configuration mechanism of a plone site should be overhauled to make it more flexible

Implementation

Analysis

First of all we will try to analyse the existing configurations and sort them into categories.

When looking at a site we can differ certain categories of configuration:

1. Roles and Permissions (RolesAndPermissionConfiguration)
2. new or changed workflows (WorkflowConfiguration)
3. types to be added, removed or modified (TypeConfiguration)
4. products to be installed (or removed) (ProductConfiguration)
5. actions to be defined, modified, deleted (ActionConfiguration)
6. portal properties to be set (PropertyConfiguration)
7. define member properties to be used (MemberPropertyConfiguration)
8. define skin paths (SkinPathConfiguration)

And then there are customizations which do not fit into any category which also need a place.

We define the following terms:

CustomizationPolicy

a set of Configurations to be applied to the site

Configuration

a singe configuration module responsible for one of the categories defined above. Will be grouped together with others to make up a !CustomizationPolicy.

Design/Architecture

The structure of the new configuration mechanism is shown in the UML diagram.

Basically a !CustomizationPolicy consists of a set of different Configurations, each of them representing one category. Most of these Configurations use a configuration file to alter the site in a specific way.

(one thing to think about might be to store the old values before changing them so there can be a rollback, though this might interfere with manual changes so I would like to not bother about it for this proposal.)

This means a change to the existing system with it's ConfigurationMethods as these are simple functions and not classes and not categorized at all (thus making it difficult to distinguish between the actual meaning of each).

Implementation

First of all the Configurations and it's derived classes will be implemented. Where possible the actual configuration will be stored in some configuration file (usually a python dictionary).

Then the !CustomizationPolicy will be reimplemented. It will define a set of Configurations which make up that policy.

Additionally tools for creating these config files could be written but this is out of the scope of this PLIP.