Class RegistryStore

source code

object --+    
         |    
      dict --+
             |
            RegistryStore

This class is responsible for loading implementations and storing them
in their registry which are created on the fly as needed.

It handles dynamic registration of objects and provides a convenient api to
access them. To be recognized as an object that should be stored into one of
the store's registry (:class:`Registry`), an object (usually a class) has
the following attributes, used control how they interact with the registry:

:attr:`__registry__` or `__registries__`
  name of the registry for this object (string like 'views', 'templates'...)
  or list of registry names if you want your object to be added to multiple
  registries

:attr:`__regid__`
  implementation's identifier in the registry (string like 'main',
  'primary', 'folder_box')

:attr:`__select__`
  the implementation's selector

Moreover, the :attr:`__abstract__` attribute may be set to `True` to
indicate that a class is abstract and should not be registered (inherited
attributes not considered).

.. Note::

  When using the store to load objects dynamically, you *always* have
  to use **super()** to get the methods and attributes of the
  superclasses, and not use the class identifier. Else, you'll get into
  trouble when reloading comes into the place.

  For example, instead of writing::

      class Thing(Parent):
          __regid__ = 'athing'
          __select__ = yes()
          def f(self, arg1):
              Parent.f(self, arg1)

  You must write::

      class Thing(Parent):
          __regid__ = 'athing'
          __select__ = yes()
          def f(self, arg1):
              super(Parent, self).f(arg1)

Controlling objects registration
--------------------------------

Dynamic loading is triggered by calling the :meth:`register_objects` method,
given a list of directory to inspect for python modules.

.. automethod: register_objects

For each module, by default, all compatible objects are registered
automatically, though if some objects have to replace other objects, or have
to be included only if some condition is met, you'll have to define a
`registration_callback(vreg)` function in your module and explicitly
register **all objects** in this module, using the api defined below.


.. automethod:: RegistryStore.register_all
.. automethod:: RegistryStore.register_and_replace
.. automethod:: RegistryStore.register
.. automethod:: RegistryStore.unregister

.. Note::
    Once the function `registration_callback(vreg)` is implemented in a
    module, all the objects from this module have to be explicitly
    registered as it disables the automatic objects registration.


Examples:

.. sourcecode:: python

   # cubicweb/web/views/basecomponents.py
   def registration_callback(store):
      # register everything in the module except SeeAlsoComponent
      store.register_all(globals().values(), __name__, (SeeAlsoVComponent,))
      # conditionally register SeeAlsoVComponent
      if 'see_also' in store.schema:
          store.register(SeeAlsoVComponent)

In this example, we register all application object classes defined in the module
except `SeeAlsoVComponent`. This class is then registered only if the 'see_also'
relation type is defined in the instance'schema.

.. sourcecode:: python

   # goa/appobjects/sessions.py
   def registration_callback(store):
      store.register(SessionsCleaner)
      # replace AuthenticationManager by GAEAuthenticationManager
      store.register_and_replace(GAEAuthenticationManager, AuthenticationManager)
      # replace PersistentSessionManager by GAEPersistentSessionManager
      store.register_and_replace(GAEPersistentSessionManager, PersistentSessionManager)

In this example, we explicitly register classes one by one:

* the `SessionCleaner` class
* the `GAEAuthenticationManager` to replace the `AuthenticationManager`
* the `GAEPersistentSessionManager` to replace the `PersistentSessionManager`

If at some point we register a new appobject class in this module, it won't be
registered at all without modification to the `registration_callback`
implementation. The previous example will register it though, thanks to the call
to the `register_all` method.

Controlling registry instantation
---------------------------------
The `REGISTRY_FACTORY` class dictionary allows to specify which class should
be instantiated for a given registry name. The class associated to `None` in
it will be the class used when there is no specific class for a name.

new empty dictionary

return the registry (dictionary of class objects) associated to
this name

register all `objects` given. Objects which are not from the module
`modname` or which are in `butclasses` won't be registered.

Typical usage is:

.. sourcecode:: python

    store.register_all(globals().values(), __name__, (ClassIWantToRegisterExplicitly,))

So you get partially automatic registration, keeping manual registration
for some object (to use
:meth:`~logilab.common.registry.RegistryStore.register_and_replace`
for instance)

register `obj` implementation into `registryname` or
`obj.__registry__` if not specified, with identifier `oid` or
`obj.__regid__` if not specified.

If `clear` is true, all objects with the same identifier will be
previously unregistered.

register `obj` implementation object into `registryname` or
`obj.__registry__` if not specified. If found, the `replaced` object
will be unregistered first (else a warning will be issued as it's
generally unexpected).

return True if something module changed and the registry should be
reloaded