1. Plugins¶
Django SHOP defines 3 types of different plugins for the time being:
- Cart modifiers
- Shipping modules
- Payment modules
1.1. Cart modifiers¶
Cart modifiers are plugins that modify the cart’s contents.
Rough categories could be discount modules or tax modules: rules for these modules are invariant, and should be “stacked”.
Example: “CDs are buy two get one free this month”, “orders over $500 get a 10% discount”
1.1.1. How they work¶
Cart modifiers should extend the
shop.cart.cart_modifiers_base.BaseCartModifier
class.
Users must register these filters in the settings.SHOP_PRICE_MODIFIERS settings entry. Modifiers will be iterated and function in the same fashion as django middleware classes.
BaseCartModifier
defines a set of methods that implementations should
override, and that are called for each cart item/cart when the cart’s
update()
method is called.
1.1.2. Example implementations¶
You can refer to the shop.cart.modifiers
package to see some example
implementations
1.2. Shipping backends¶
Shipping backends differ from price modifiers in that there must be only one shipping backend selected per order (the shopper must choose which delivery method to use)
Shipping costs should be calculated on an Order
object,
not on a Cart
object (Order
instances are fully serialized in the database for archiving purposes).
1.2.1. How they work¶
Shipping backends need to be registered in the SHOP_SHIPPING_BACKENDS Django setting. They do not need to extend any particular class, but need to expose a specific interface, as defined in Backend interface.
The core functionality the shop exposes is the ability to retrieve the current
Order
object (and all it’s related bits and pieces such
as extra price fields, line items etc...) via a convenient
self.shop.get_order()
call. This allows for your module to be reused
relatively easily should another shop system implement this interface.
On their part, shipping backends should expose at least a get_urls()
method, returning a urlpattern
-style list or urls. This allows backend
writers to have almost full control of the shipping process (they can create
views and make them available to the URL resolver).
Please note that module URLs should be namespaced, and will be added to the
ship/
URL namespace. This is a hard limitation to avoid URL name clashes.
1.3. Payment backends¶
Payment backends must also be selected by the end user (the shopper). Theses modules take care of the actual payment processing.
1.3.1. How they work¶
Similar to shipping backends, payment backends do not need to extend any particular class, but need to expose a specific interface, as defined in Backend interface.
They also obtain a reference to the shop, with some convenient methods defined
such as self.shop.get_order()
.
They must also define a get_urls()
method, and all defined URLs will be
namespaced to pay/
.