Package: django-appregistration
django-appregistrationThis app provides a base class to easily realize django apps that allow
other apps to register parts in it.Requirements:Django >= 1.6InstallationFrom the pip repository:pip installdjango-appregistrationor directly from github:pip installgit+git://github.com/NB-Dev/django-apregistration.gitUsagedjango-appregistration provides two base classes for the registration of
modules from other apps:MultiListPartRegistryandSingleListPartRegistry. While both have the same basic
functionality, in theMultiListPartRegistrymultiple distinct lists
of objects can be collected, theSingleListPartRegistryonly
contains a single list.To implement a...PartRegistryin your app, create a subclass of the...PartRegistryor your choice in a convenient place in your
application. There are some attributes you can overwrite in your
Subclass:part_class(required): The (parent) class of the objects that are
allowed to be inserted into your Registrycall_function_subpath(required): The subpath to the function
that is to be called by the registry on load (details, see below)ignore_django_namespace(default: True): If true, any app that
starts withdjango.in yourINSTALLED_APPSwill be ignored on
load time.To prevent arbitrary items to be inserted into your Registry the...PartRegistryclasses check each added element to be an instance
of the class that is set as thepart_classattribute of the your
Registry.When the Registry tries to load elements from theINSTALLED_APPS, it
iterates over the apps and tries, for each to get the sub module /
function that is defined in thecall_function_subpath. It then
checks if the retrieved object is callable and calls it if so passing
the Registry itself as only call parameter.To register elements with the Registry you therefore need to implement
the appropriate function atcall_function_subpathin an app that is
listed in theINSTALLED_APPS. The implemented function then needs to
call theadd_itemfunction on the passed registry.To further simplify the usage of dynamic apps, the app provides afilter_available_appsfunction that filters a list of possible apps
and returns only the ones that are available in the current
installation. This allows for a highly dynamic configuration of django
projects by allowing certain apps to be installed selectively. Use it in
yoursettings.pyto dynamically add the available apps to yourINSTALLED_APPSFile: settings.pyfrom django_appregistration import filter_available_apps
INSTALLED_APPS = [
    'imported_app1',
    'imported_app2',
    'imported_app3',
    ...
] + filter_available_apps(
    'optional_app1',
    'optional_app2',
    'optional_app3',
    ...
)ExampleHere is an implementation example with a Registry implemented in theextendable_appapp and an appextending_appthat extends the
RegistryFile: extendable_app.registry.pyfrom django_appregistration import MultiListPartRegistry

class MyRegisterable(object):
   pass

class MyRegistry(MultiListPartRegistry):
   part_class = MyRegisterable
   call_function_subpath = 'registerable.register'File: extending_app.registerable.pydef register(registry):
   # import inside the function so that the import is only needed if the registry is used
   # and the package is therefore available
   from extendable_app.registry import MyRegisterable

   registry.add_part('default', MyRegisterable())
   registry.add_part('other', MyRegisterable())Like this theextending_appregisters two parts when the registry is
loaded, one in the listdefaultand one in the listother.The objects can be retrieved like so:from extendable_app.registry import MyRegistry
default_parts = MyRegistry.get('default') # retrieves the `default` list
other_parts = MyRegistry.get('other') # retrieves the `other` listAPIAPI documetationMultiListPartRegistry(object)The following functions are available:add_part(list, part)Adds the part given by thepartparameter to the list with the name
given by thelistparameter.get(list)Returns the parts in the list with the name given by thelistparameter. The elements are sorted before they are returned.sort_parts(parts)Can be overwritten to define a custom ordering of the parts. The default
function simply returns the list unordered.load()When called, the class is initialized and loads the available parts into
its list cache. Does nothing if theload()was already called. Is
called automatically by theget()function. There is no need to call
it explicitly unless you want to initialize the class before the first
list is retrieved.reset()Resets the Registry to its initial state so that the parts will be
reloaded the next time theload()function is called. Usually there
is no need to call this as it only adds extra overhead when the parts
need to be loaded again.SingleListPartRegistry(MultiListPartRegistry)The following functions are additionally available:add_part(part)Adds the part given by thepartparameter to the list.get()Returns the parts in the list. The elements are sorted before they are
returned.Running the testsThe included tests can be run standalone by running thetests/runtests.pyscript. You need to have Django and mock installed
for them to run. If you also want to run coverage, you need to install
it before running the testsChangelogv0.0.6 (2017-05-19)Fixing README heading levelsv0.0.5 (2017-05-19)Adding support for Django 1.10 and 1.11v.0.0.4Adding thefilter_available_appsfunction that checks a list of
given apps for their availability.v.0.0.3Bugfix: Also moved thelockand theloadedattributes into
the meta classv.0.0.2Bugfix: Using a metaclass to separate the lists for each subclass ofMultiListPartRegistry. Before each registry used the same list
resulting in element mixtures if more than one registry was usedv.0.0.1aRenameTypetoListin classesv.0.0.1Initial implementation ofMultiTypePartRegistryandSingleTypePartRegistryMaintainersThis Project is maintained byNorthbridge Development Konrad &
Schneider GbRSoftwareentwicklung.