forked from CGM_Public/pretix_original
Add documentation
This commit is contained in:
@@ -121,6 +121,7 @@ This will automatically make pretix discover this plugin as soon as it is instal
|
||||
through ``pip``. During development, you can just run ``python setup.py develop`` inside
|
||||
your plugin source directory to make it discoverable.
|
||||
|
||||
.. _`Signals`:
|
||||
Signals
|
||||
-------
|
||||
|
||||
@@ -153,6 +154,28 @@ in the ``installed`` method:
|
||||
Note that ``installed`` will *not* be called if the plugin is indirectly activated for an event
|
||||
because the event is created with settings copied from another event.
|
||||
|
||||
.. _`Registries`:
|
||||
Registries
|
||||
----------
|
||||
|
||||
Many signals in pretix are used so that plugins can "register" a class, e.g. a payment provider or a
|
||||
ticket renderer.
|
||||
|
||||
However, for some of them (types of :ref:`Log Entries <logging>`) we use a different method to keep track of them:
|
||||
In a ``Registry``, classes are collected at application startup, along with a unique key (in case
|
||||
of LogEntryType, the action_type) as well as which plugin registered them.
|
||||
|
||||
To register a class, you can use one of several decorator provided by the Registry object:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
@log_entry_types.new('my_pretix_plugin.some.action', _('Some action in My Pretix Plugin occured.'))
|
||||
class MyPretixPluginLogEntryType(EventLogEntryType):
|
||||
pass
|
||||
|
||||
All files in which classes are registered need to be imported in the ``AppConfig.ready`` as explained
|
||||
in `Signals`_ above.
|
||||
|
||||
Views
|
||||
-----
|
||||
|
||||
|
||||
Reference in New Issue
Block a user