Issue #112 resolved

New configuration file plan (including options for filters)

Anonymous created an issue

On the IRC meeting (see IrcSession20050209). it was decided that:

  1. the config file will be kept in the INI format (as it is today)
  2. sections will map to the cpg object hierarchy
  3. attributes in the INI file will be mapped to attributes in the objects.
  4. Filters will be configurable as objects in the cpg hierarchy.
  5. filters will be declared in three lists: {{{defaultInputFilterList}}}, {{{_cpFilterList}}}, {{{defaultOutputFilterList}}}.
  6. The final filterList is the concatenation: {{{defaultInputFilterList, _cpFilterList, defaultOutputFilterList}}}.
    • Any of them can be overriden in code.
    • The standard {{{_cpFilterList}}} is empty, and the user can supply additional filters that will neatly fit in the middle of the chain.
  7. default filters are named, using the usual Python convention. For example, the default {{{EncodingFilter}}} can be acessed as the {{{encodingFilter}}} (starting with lowercase) attribute in the config file.

== Config file sample ==

{{{ [root] encodingFilter.encoding = latin1 }}}


  • {{{encodingFilter}}} is the name of the filter;
  • {{{encoding}}} is an attribute of the {{{encodingFilter}}};
  • {{{latin1}}} is a string, it's passed to the encoding attribute.
  • Values are passed as string, all type conversion is done by the attribute itself. It is still not clear if the attribute setting will be handled by a method or my a descriptor/property in the filter object.

== Notes ==

This ticket will probably be split into a few sub-tickets, because there's a lot of changes. This ticket should only be closed when the entire task is completed. Sub-tickets should be cited here as additional comments on this ticket.

Reported by cribeiro

Comments (6)

  1. Anonymous

    That's a sample config file, dealing with filters. It was presented by Remi in the IRC:

    encodingFilter = on
    encodingFilter.encoding = latin1
    cacheFilter = on
    cacheFilter.timeout = 60
    gzipFilter = on
    encodingFilter.encoding = utf8
    cacheFilter.timeout = 30

    As noted by Remi, the example above leaves important questions to be answered:

    • what instances of filters will be created?
    • when will they be created? by who?
    • how many different filterList lists will we have? what will they be?
  2. Anonymous


    • Revision [154].
    • Implemented and tested the _cpmagicattr module.
    • Passes all tests.

    Implementation notes

    The new system assumes that '''all''' accesses to the configuration information pass through the same system. Magic functions and config values can be set and read using the same API. The cpg.getConfig() provides a standard way to read the information. To set configuration data, the programmer can:

    • use a config dictionary.
    • use a configuration file
    • set the equivalent attributes on code.

    Precedence is as follows: 1. configuration; 2. attributes in code; 3. default values (provided in a dictionary).

    CherryPy provides default values for all its internal configuration options in the _cpconfig module.

    Filters, and other add-on modules should provide their own default values, by means of the setDefaultAttr() and setDefaultMap methods.

    Accesses to the cpg.configMap should be directed through the cpg.getConfig() method. The module implements caching at several levels. Preliminary testing (running the module directly on the prompt) indicates that the caching is highly effective when accessing magic attributes, with a 10x improvement over the search procedure.

    The configuration data is kept split in two dictionaries, named defaultMap and configMap. There are some specific advantages and disadvantages for this approach. It involves a little bit more work; however, it makes possible to always check the default value for an attribute. The default value is used to define the type of the attribute, and allows '''automatic type conversion'''. This feature was not still discussed, and may be removed from the code before this ticket is closed.

    Another advantage of the split default & config design is that configuration can be erased, or reloaded, at runtime. Every reload always restart from the original defaults. Other solutions could be implemented, but this one is already working.

    Open issues

    • The special cpg.request.cpgattr attribute wasn't still created. It can be used to retrieve configuration values from the point of view of a given node in the cpg hierarchy.
    • The staticContent session poses a problem for the new configuration system. It contain arbirtrary attributes, and is often accessed as a dicionary. We implemented a workaround, returning the configMap entry when the getConfig() method is called with a single argument ('staticContent', usually).
  3. Log in to comment