Last modified 7 years ago Last modified on 05/29/11 20:20:14

Registry Framework

This page is for future nodewatcher version currently in development.

nodewatcher's registry framework enables modular and extensible registration of Django models. There can be multiple registry namespaces (or registration points) inside one project/application. Each registration point is bound to exactly one root model under its name, but multiple registration points can be bound to the same model (with different names). For example, the node configuration registry is bound to the Node model under the name config which gives the registration point identifier node.config. Creating a registration point on some root model also replaces the model's default Manager (see Django documentation for details on managers) so querysets gain some convenience methods for querying over the root's registry.

The registry structure is made up of standard Django models with minor extensions. There are three types of models:

Top-level registry item
Represents the anchor point in registry space by defining an identifier and base schema. Other registry items can then extend this top-level item by subclassing it and adding fields/functionality. All registry items that share the same parent class are available under the same identifier.
Registry item
A model that descends from some other registry item (top-level or otherwise).
Registry subitem
A standard registry item that is linked by IntraRegistryForeignKey to some other registry items, thus creating a dynamic (runtime editable) hierarchy of items.

The framework can also generate forms from these models that can be used for configuring the root item to which a registration point is bound. Each registration point has its own namespace that is made up of string identifiers, defined by top-level registry items. For example core.general (see node.config schema) is such an identifier that represents GeneralConfig and all its subclasses.

Registry Item Metadata

Each registry item may (or must if it is top-level) define some metadata describing its operational details. This is represented by declaring a RegistryMeta class inside the model (in a fashion similar to Django's Meta class). There are multiple possible attributes that can be used:

Specifies the order where this item will be placed when rendering a form.
Specifies the registry identifier for this item and all its subclasses (should only be set by the top-level item).
Section name that is used when rendering forms (as a title for all subclasses under the same registry_id).
Item name that is used for displaying a title of this specific subclass.
See the below section on item cardinality.
See the below section on item cardinality.
Should the top-level always be hidden when rendering forms.
Should registering this item hide the parent item when rendering forms.

An example of such metadata is as follows:

  class CgmInterfaceConfig(registration.bases.NodeConfigRegistryItem):
    # ... (fields) ...
    class RegistryMeta:
      form_order = 50
      registry_id = "core.interfaces"
      registry_section = _("Network Interface Configuration")
      registry_name = _("Generic Interface")
      multiple = True
      hidden = True

Registry Item Cardinality

Each top-level registry item may define a cardinality for its items (itself and subclasses). It can be one of the following:

Only one instance of this class may be set. In case multiple subclasses exist, any of them (but only one at a time) can be configured. This is the default.
Multiple instances of this class may be set (the form will display add/remove options). In case multiple subclasses exist, any of them (but only one at a time) can be configured for each instance. This cardinality must be indicated by setting multiple = True in registry item metadata.
Multiple but Static
All of the subclasses must be set (the form will always display all registered subclasses). This cardinality must be indicated by setting multiple_static = True in addition to setting the multiple = True in registry item metadata.




Dynamic Forms and Fields

Sometimes a field's type/content depends on values of other fields.


  • partially validated configuration concept
  • how to write such fields/forms
  • dependency ordering is important