[checkmk-commits] [tribe29/checkmk] cbf5b1: Plugin registry: Add decorator for registering cla...

Branch: refs/heads/master Home: https://github.com/tribe29/checkmk Commit: cbf5b197f3b0ed4ee681978d68e9117e7c4784cc https://github.com/tribe29/checkmk/commit/cbf5b197f3b0ed4ee681978d68e9117e7… Author: Lars Michelsen <lm(a)tribe29.com> Date: 2020-09-09 (Wed, 09 Sep 2020) Changed paths: M cmk/utils/plugin_registry.py M tests/unit/cmk/utils/test_plugin_registry.py Log Message: ----------- Plugin registry: Add decorator for registering class instances Previously you had to specify the class declaration and instantiation with registration in separate blocks, like this: class DecoratedPlugin(Plugin): pass plugin_registry.register(DecoratedPlugin()) With the new decorator it is possible to register class instances to an instance registry next to the class declaration: @registry.register_instance class DecoratedPlugin(Plugin): pass Change-Id: Iff41d441b70987a94e7f0c223ea34651449cf84c Commit: 80978cdb4281aca40a206978f394b1827a40c125 https://github.com/tribe29/checkmk/commit/80978cdb4281aca40a206978f394b1827… Author: Lars Michelsen <lm(a)tribe29.com> Date: 2020-09-09 (Wed, 09 Sep 2020) Changed paths: M cmk/gui/mkeventd.py M cmk/gui/plugins/views/inventory.py M cmk/gui/plugins/visuals/filters.py M cmk/gui/plugins/visuals/inventory.py M cmk/gui/plugins/visuals/utils.py M cmk/gui/plugins/visuals/wato.py M cmk/gui/visuals.py M tests/unit/cmk/gui/plugins/visuals/test_filters.py M tests/unit/cmk/gui/test_visuals.py Log Message: ----------- Refactor filter_registry to objects All call sites to the registry create instances from the filter. Direcly getting instances from the registry simplifies the call sites. Having a dedicated class for each filter is consuming more memory than having just a number of classes with one instance for each filter. The filters were previously all registered with their classes in the registry. Even the dynamically created inventory filters that are all based on a small number of classes was creating and registering a dedicated class each registered filter. This structure was originally chosen, because the filters are registered on module level with all their attributes, including localizable strings (title, description), but the localization information is not loaded during module loading, making these strings not localizable. Since we have extended our GUI framework with speaklater, which allows us to declare lazy localizations (using _l() instead of _()), we can now declare localized strings during module load time. Change-Id: I889bbdd6c19dab1d4d9a4ef5cc7103b39a066673 Compare: https://github.com/tribe29/checkmk/compare/4897e014be21...80978cdb4281