|
|
@@ -0,0 +1,36 @@
|
|
|
1
|
+================
|
|
|
2
|
+Design decisions
|
|
|
3
|
+================
|
|
|
4
|
+
|
|
|
5
|
+Oscar's is designed to be open to customisation wherever possible. There are two
|
|
|
6
|
+main ways in which this is acheived.
|
|
|
7
|
+
|
|
|
8
|
+Dynamic importing of classes
|
|
|
9
|
+----------------------------
|
|
|
10
|
+
|
|
|
11
|
+Within oscar itself, classes are imported using a special ``import_module`` function
|
|
|
12
|
+which determines which app to load the specified classes from. Sample usage is::
|
|
|
13
|
+
|
|
|
14
|
+ import_module('product.models', ['Item', 'ItemClass'], locals())
|
|
|
15
|
+
|
|
|
16
|
+This will load the ``Item`` and ``ItemClass` classes into the local namespace. It is
|
|
|
17
|
+a replacement for the usual::
|
|
|
18
|
+
|
|
|
19
|
+ from oscar.product.models import Item, ItemClass
|
|
|
20
|
+
|
|
|
21
|
+The ``import_module`` looks through your ``INSTALLED_APPS`` for a matching module to
|
|
|
22
|
+the one specified and will load the classes from there. If the matching module is
|
|
|
23
|
+not from oscar's core, then it will also fall back to the equivalent module if the
|
|
|
24
|
+class cannot be found.
|
|
|
25
|
+
|
|
|
26
|
+This structure enables a project to create a local ``product.models`` module and
|
|
|
27
|
+subclass and extend the core models from ``oscar.app.product.models``. When Oscar
|
|
|
28
|
+tries to load the ``Item`` class, it will load the one from your local project.
|
|
|
29
|
+
|
|
|
30
|
+Class-based views
|
|
|
31
|
+-----------------
|
|
|
32
|
+
|
|
|
33
|
+All views within oscar's core are class-based, which allows the above dynamic class
|
|
|
34
|
+loading to be used within ``urls.py`` modules, so that core views can be subclassed
|
|
|
35
|
+within projects to extend and customised them.
|
|
|
36
|
+
|