forked from CGM_Public/pretix_original
Fixed minor documentation errors and mistakes (#151)
This commit is contained in:
Tobias Kunze
committed by
Raphael Michel
Raphael Michel
parent
f779b70deb
commit
bfc721978d
@@ -4,7 +4,7 @@
|
||||
Writing an exporter plugin
|
||||
==========================
|
||||
|
||||
An is a method to export the product and order data in pretix for later use in another
|
||||
An Exporter is a method to export the product and order data in pretix for later use in another
|
||||
context.
|
||||
|
||||
In this document, we will walk through the creation of an exporter output plugin. This
|
||||
@@ -18,7 +18,7 @@ Exporter registration
|
||||
The exporter API does not make a lot of usage from signals, however, it does use a signal to get a list of
|
||||
all available exporters. Your plugin should listen for this signal and return the subclass of
|
||||
``pretix.base.exporter.BaseExporter``
|
||||
that we'll soon create::
|
||||
that we'll provide in this plugin::
|
||||
|
||||
from django.dispatch import receiver
|
||||
|
||||
@@ -36,8 +36,7 @@ The exporter class
|
||||
|
||||
.. class:: pretix.base.exporter.BaseExporter
|
||||
|
||||
The central object of each exporter is the subclass of ``BaseExporter`` we already mentioned above.
|
||||
In this section, we will discuss it's interface in detail.
|
||||
The central object of each exporter is the subclass of ``BaseExporter``.
|
||||
|
||||
.. py:attribute:: BaseExporter.event
|
||||
|
||||
|
||||
@@ -60,8 +60,8 @@ Dashboards
|
||||
:members: event_dashboard_widgets, user_dashboard_widgets
|
||||
|
||||
|
||||
Displaying of log entries
|
||||
-------------------------
|
||||
Display of log entries
|
||||
----------------------
|
||||
|
||||
.. automodule:: pretix.base.signals
|
||||
:members: logentry_display
|
||||
|
||||
@@ -14,7 +14,7 @@ Provider registration
|
||||
The payment provider API does not make a lot of usage from signals, however, it
|
||||
does use a signal to get a list of all available payment providers. Your plugin
|
||||
should listen for this signal and return the subclass of ``pretix.base.payment.BasePaymentProvider``
|
||||
that we'll soon create::
|
||||
that the plugin will provide::
|
||||
|
||||
from django.dispatch import receiver
|
||||
|
||||
@@ -32,8 +32,7 @@ The provider class
|
||||
|
||||
.. class:: pretix.base.payment.BasePaymentProvider
|
||||
|
||||
The central object of each payment provider is the subclass of ``BasePaymentProvider``
|
||||
we already mentioned above. In this section, we will discuss it's interface in detail.
|
||||
The central object of each payment provider is the subclass of ``BasePaymentProvider``.
|
||||
|
||||
.. py:attribute:: BasePaymentProvider.event
|
||||
|
||||
@@ -105,9 +104,9 @@ Additional views
|
||||
For most simple payment providers it is more than sufficient to implement
|
||||
some of the :py:class:`BasePaymentProvider` methods. However, in some cases
|
||||
it is necessary to introduce additional views. One example is the PayPal
|
||||
provider. It redirects the user to a paypal website in the
|
||||
:py:meth:`BasePaymentProvider.checkout_prepare`` step of the checkout process
|
||||
and provides PayPal with an URL to redirect back to. This URL points to a
|
||||
provider. It redirects the user to a PayPal website in the
|
||||
:py:meth:`BasePaymentProvider.checkout_prepare` step of the checkout process
|
||||
and provides PayPal with a URL to redirect back to. This URL points to a
|
||||
view which looks roughly like this::
|
||||
|
||||
@login_required
|
||||
@@ -123,7 +122,7 @@ view which looks roughly like this::
|
||||
try:
|
||||
# Redirect back to the confirm page. We chose to save the
|
||||
# event ID in the user's session. We could also put this
|
||||
# information into an URL parameter.
|
||||
# information into a URL parameter.
|
||||
event = Event.objects.current.get(identity=request.session['payment_paypal_event'])
|
||||
return redirect(reverse('presale:event.checkout.confirm', kwargs={
|
||||
'event': event.slug,
|
||||
@@ -136,6 +135,6 @@ view which looks roughly like this::
|
||||
|
||||
If you do not want to provide a view of your own, you could even let PayPal
|
||||
redirect directly back to the confirm page and handle the query parameters
|
||||
inside :py:meth:`BasePaymentProvider.checkout_is_valid_session``. However,
|
||||
inside :py:meth:`BasePaymentProvider.checkout_is_valid_session`. However,
|
||||
because some external providers (not PayPal) force you to have a *constant*
|
||||
redirect URL, it might be necessary to define custom views.
|
||||
|
||||
@@ -6,7 +6,7 @@ Plugin basics
|
||||
|
||||
It is possible to extend pretix with custom Python code using the official plugin
|
||||
API. Every plugin has to be implemented as an independent Django 'app' living
|
||||
in an own python package nstalled like any other python module. There are also some
|
||||
in its own python package installed like any other python module. There are also some
|
||||
official plugins inside the ``pretix/plugins/`` directory of your pretix installation.
|
||||
|
||||
The communication between pretix and the plugins happens mostly using Django's
|
||||
@@ -16,13 +16,13 @@ on the next pages.
|
||||
|
||||
.. _`pluginsetup`:
|
||||
|
||||
To create a new plugin, create a new python package which must be a vaild `Django app`_
|
||||
To create a new plugin, create a new python package which must be a valid `Django app`_
|
||||
and must contain plugin metadata, as described below.
|
||||
|
||||
The following pages go into detail about the several types of plugins currently
|
||||
supported. While these instructions don't assume that you know a lot about pretix,
|
||||
they do assume that you have prior knowledge about Django (e.g. it's view layer,
|
||||
how it's ORM works, etc.).
|
||||
they do assume that you have prior knowledge about Django (e.g. its view layer,
|
||||
how its ORM works, etc.).
|
||||
|
||||
Plugin metadata
|
||||
---------------
|
||||
@@ -83,7 +83,7 @@ Plugin registration
|
||||
|
||||
Somehow, pretix needs to know that your plugin exists at all. For this purpose, we
|
||||
make use of the `entry point`_ feature of setuptools. To register a plugin that lives
|
||||
in a seperate python package, your ``setup.py`` sould contain something like this::
|
||||
in a separate python package, your ``setup.py`` should contain something like this::
|
||||
|
||||
setup(
|
||||
…
|
||||
@@ -129,4 +129,4 @@ your Django app label.
|
||||
.. _Django app: https://docs.djangoproject.com/en/1.7/ref/applications/
|
||||
.. _signal dispatcher: https://docs.djangoproject.com/en/1.7/topics/signals/
|
||||
.. _namespace packages: http://legacy.python.org/dev/peps/pep-0420/
|
||||
.. _entry point: https://pythonhosted.org/setuptools/setuptools.html#dynamic-discovery-of-services-and-plugins
|
||||
.. _entry point: https://pythonhosted.org/setuptools/setuptools.html#dynamic-discovery-of-services-and-plugins
|
||||
|
||||
@@ -17,7 +17,7 @@ Output registration
|
||||
The ticket output API does not make a lot of usage from signals, however, it
|
||||
does use a signal to get a list of all available ticket outputs. Your plugin
|
||||
should listen for this signal and return the subclass of ``pretix.base.ticketoutput.BaseTicketOutput``
|
||||
that we'll soon create::
|
||||
that we'll provide in this plugin::
|
||||
|
||||
from django.dispatch import receiver
|
||||
|
||||
@@ -35,8 +35,7 @@ The output class
|
||||
|
||||
.. class:: pretix.base.ticketoutput.BaseTicketOutput
|
||||
|
||||
The central object of each ticket output is the subclass of ``BaseTicketOutput``
|
||||
we already mentioned above. In this section, we will discuss it's interface in detail.
|
||||
The central object of each ticket output is the subclass of ``BaseTicketOutput``.
|
||||
|
||||
.. py:attribute:: BaseTicketOutput.event
|
||||
|
||||
|
||||
Reference in New Issue
Block a user