{
"info": {
"author": "Martin Aspeli",
"author_email": "optilude@gmail.com",
"bugtrack_url": null,
"classifiers": [
"Framework :: Plone",
"Framework :: Plone :: 5.1",
"Framework :: Plone :: 5.2",
"License :: OSI Approved :: GNU General Public License (GPL)",
"Programming Language :: Python",
"Programming Language :: Python :: 2.7",
"Programming Language :: Python :: 3.6",
"Programming Language :: Python :: 3.7",
"Topic :: Software Development :: Libraries :: Python Modules"
],
"description": "Introduction\n============\n\n``plone.app.registry`` provides Plone UI and GenericSetup integration for\n`plone.registry`_, which in turn implements a configuration registry for\nZope applications. For details about how the registry works, please see the\n`plone.registry`_ documentation. What follows is a brief overview of common\nusage patterns in Plone.\n\n.. contents:: Table of contents\n\nOverview\n========\n\nThe registry provided by `plone.registry`_ is intended to store settings in\na safe, easily accessible manner. This makes it well-suited for applications\nand add-on products that need to manage some configurable, user-editable\nvalues. It is intended to replace the use of (less powerful and user friendly)\nZope 2 property sheets, as well as (less safe and more difficult to access)\npersistent local utilities for managing such configuration.\n\nThe registry is *not* an arbitrary data store. For the most part, you can\nstore any Python primitive there, but not more complex data structures or\nobjects. This means that the registry cannot be broken by packages being\nuninstalled, and that it can provide a simple, generic user interface for\nediting values.\n\nThe registry is made up of *records*. A record consists of a *field*,\ndescribing the record, and a *value*. Fields are based on the venerable\n``zope.schema``, although the standard allowable field types are defined in\nthe module ``plone.registry.field``. (This is partly because the field\ndefinitions are actually persisted with the record, and partly because\n``plone.registry`` performs some additional validation to ensure the integrity\nof the registry).\n\nA record can be created programmatically, though in a Plone context it is more\ncommon to install records using the ``records.xml`` GenericSetup syntax. Once\nthe record has been created, its value can be read and set using standard\nPython dictionary syntax. Accessing the record and field is just as easy.\n\nEach record has a unique name, which must be a *dotted name* prefixed by the\npackage owning the record. For example, a record owned by the package\n``my.package`` could have a name like ``my.package.myrecord``.\n\nAs of version 1.6, it is possible to split ``registry.xml`` into\nmultiple files; to import and export registry entries via the control\npanel; and to add and delete records via the control panel.\n\nNotes about versions\n====================\n\n- versions 1.3 and later are for Plone 5.\n\n- versions 1.2.x are for Plone 4.\n\nUsage\n=====\n\nThis section describes how the registry is most commonly used in a Plone\ncontext. For more details, please see the `plone.registry`_ documentation.\n\nUsing GenericSetup to manipulate the registry\n---------------------------------------------\n\nThe best way to create, modify and delete registry records when writing Plone\nadd-on products is normally to use GenericSetup.\n\nCreating records\n~~~~~~~~~~~~~~~~\n\nOnce you have decided that you need a particular record, you need to answer\ntwo questions:\n\n1. What should the record be called?\n2. What type of data should it hold?\n\nLet's say you wanted to create a record call ``my.package.timeout``, holding\nan integer. Integers are described by the field type\n``plone.registry.field.Int``. Almost all the standard fields you would find\nin ``zope.schema`` have an equivalent field in ``plone.registry.field``. The\nmain exception is ``Object``, which is unsupported. Also, ``Choice`` fields\nonly support vocabularies given by string name, or as a list of string values.\nFinally, you cannot use the ``constraint`` property to set a validator\nfunction, although other validation (such as min/max values) will work.\n\nTo install such a record, you could add a ``registry.xml`` step to the\nGenericSetup profile of your product like this::\n\n