2015-05-08 18:44:44 +03:00
|
|
|
Catalogs
|
|
|
|
========
|
2015-07-28 09:46:35 +03:00
|
|
|
|
2015-08-04 17:05:34 +03:00
|
|
|
Catalogs are collections of providers. Main purpose of catalogs is to group
|
|
|
|
providers.
|
|
|
|
|
|
|
|
There are, actually, several popular use cases of catalogs:
|
|
|
|
|
|
|
|
- Grouping of providers from same architectural layer (for example,
|
|
|
|
``Services``, ``Models`` and ``Forms`` catalogs).
|
|
|
|
- Grouping of providers from a same functional components (for example,
|
|
|
|
catalog ``Users``, that contains all functional parts of ``Users``
|
|
|
|
component).
|
|
|
|
|
2015-08-05 16:44:00 +03:00
|
|
|
Als, for both of these and some other cases, it might be useful to attach
|
|
|
|
some init / shutdown functionality or something else, that deals with group
|
|
|
|
of providers.
|
|
|
|
|
2015-07-28 09:46:35 +03:00
|
|
|
Writing catalogs
|
|
|
|
----------------
|
|
|
|
|
2015-08-04 17:05:34 +03:00
|
|
|
Catalogs have to be created by extending base catalog class
|
2015-08-31 16:31:38 +03:00
|
|
|
``dependency_injector.catalog.AbstractCatalog``.
|
2015-08-04 17:05:34 +03:00
|
|
|
|
|
|
|
Providers have to be defined like catalog's attributes. Every provider in
|
|
|
|
catalog has name. This name should follow ``some_provider`` manner, that is
|
|
|
|
standard naming convention for names of attributes in Python.
|
|
|
|
|
|
|
|
.. note::
|
|
|
|
|
|
|
|
It might be useful to add such
|
2015-08-31 16:31:38 +03:00
|
|
|
``""":type: (dependency_injector.Provider) -> Object1"""`` documentation
|
|
|
|
blocks one line after provider definition for every provider. It will help
|
|
|
|
code analysis tools and IDE's to understand that variable above contains
|
|
|
|
some callable object, that returns particular instance as a result of call.
|
2015-08-04 17:05:34 +03:00
|
|
|
|
|
|
|
Example:
|
|
|
|
|
2015-08-05 16:44:00 +03:00
|
|
|
.. image:: /images/catalogs/simple.png
|
|
|
|
:width: 100%
|
|
|
|
:align: center
|
|
|
|
|
2015-08-05 17:24:03 +03:00
|
|
|
.. literalinclude:: ../../examples/catalogs/simple.py
|
2015-08-04 17:05:34 +03:00
|
|
|
:language: python
|
|
|
|
|
2015-08-05 16:44:00 +03:00
|
|
|
Operating with catalog providers
|
|
|
|
--------------------------------
|
|
|
|
|
|
|
|
There are several things that could be useful for operating with catalog
|
|
|
|
providers:
|
|
|
|
|
|
|
|
- First of all, ``Catalog.providers`` attribute contains ``dict`` with all
|
|
|
|
catalog providers and their catalog names. This dictionary could be used
|
|
|
|
for any kind of operations that could be done with providers. The only note,
|
|
|
|
is that ``Catalog.providers`` attribute is read-only.
|
|
|
|
- Second one, ``Catalog.filter(provider_type=Provider)`` method could be
|
|
|
|
used for filtering catalog providers by provider types (for example, for
|
|
|
|
getting all ``Factory`` providers).
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
2015-08-05 17:24:03 +03:00
|
|
|
.. literalinclude:: ../../examples/catalogs/operating_with_providers.py
|
2015-08-05 16:44:00 +03:00
|
|
|
:language: python
|
|
|
|
|
2015-08-04 17:05:34 +03:00
|
|
|
Overriding of catalogs
|
|
|
|
----------------------
|
|
|
|
|
|
|
|
Catalogs can be overridden by other catalogs. This, actually, means that
|
|
|
|
all of the providers from overriding catalog will override providers with the
|
|
|
|
same names in overridden catalog.
|
|
|
|
|
|
|
|
There are two ways to override catalog by another catalog:
|
|
|
|
|
|
|
|
- Use ``Catalog.override(Catalog)`` method.
|
|
|
|
- Use ``@override(Catalog)`` class decorator.
|
|
|
|
|
|
|
|
Example of overriding catalog using ``Catalog.override()`` method:
|
|
|
|
|
2015-08-05 17:24:03 +03:00
|
|
|
.. literalinclude:: ../../examples/catalogs/override.py
|
2015-08-04 17:05:34 +03:00
|
|
|
:language: python
|
|
|
|
|
|
|
|
Example of overriding catalog using ``@override()`` decorator:
|
2015-07-28 09:46:35 +03:00
|
|
|
|
2015-08-05 17:24:03 +03:00
|
|
|
.. literalinclude:: ../../examples/catalogs/override_decorator.py
|
2015-08-04 17:05:34 +03:00
|
|
|
:language: python
|