Requirements

In the time when created djWarehouse, we already had some experience of building e-commerce stores. According to this experience, we understood that there are nothing ideal, and every e-commerce site we've built usually required to change (partly or completely):

  • product attrubutes and options
  • site flow
  • shipment options
  • payment options
  • procedures of order processing

According to this, we had to admit that all above things are float, and we should not hardcode any of them. Instead, try to be maximally agile and allow developers to configure their e-commerce store 1:1 as customer see it.

What comes to 'djw/core' and why

OK, still, there must be some reasonable default which we share between *all* sites, this is the main purpose of the djWarehouse as product itself - to provide a connection between e-commerce store applications.

The following is in djw/core:

  • ProductCatalog - core part of ProductCatalog
  • Cart - This is very basic storage for user products
  • Customer - A table, which connects to django.contrib.auth.User via OneToOne? field and store developer can customize it.
  • Discount - Discount plugins manager.
  • docs - Documentation and Django patches
  • media - media files for djWarehouse. It should be linked to djwstatic directory in /htdocs
  • Order
  • Payment - Payment modules manager
  • Promotion - Promotion modules manager
  • Search - Product Catalog search. Includes FullTextSearch?.
  • settings - django settings, but split to a few files
  • Shipment - Shipment modules manager application
  • Tax - Tax modules application
  • templates - core templates
  • tests - Unit, and other tests
  • UserRequest? - a system to store & process user requests
  • utils - different utils
  • widget - newforms additional widgets used in djWarehouse
  • XMLHttp - decorators and other stuff for AJAX interactions

settings

djWarehouse is typical Django application, so it have its settings. But, the difference is that we would like to have a few defaults by the way:

  • djw/core/settings/default.py - those are djw/core defaults - this file is shared between all djWarehouse installations
  • djw/core/settings/settings.py - settings for the current installation
  • djw/core/settings/local_paths.py - project paths (so we don't repeat them amoung different settings files)
  • djw/custom/project_settings.py - project settings, so we don't repeat them between different installs of same project

Product catalog

The main trouble for any product catalog is to solve problem of how to handle different kinds of product attributes. Solution explained here is a good one, but is not yet 100% complete, and we are constantly improving it.

The approach which we use (until Inheritance is fully usable) is to connect additional product information via OneToOne model to a typical product fields set in djw/core.

This way we connect djw/custom/ProductCatalog_custom/models.py to djw/core/ProductCatalog/models.py

So, in Django admin, every product have 'core' and 'custom' parts, where custom is specified by core admin. See for example how we extended product attributes for 'bookstore demo': http://djwarehouse.org/browser/demo.djwarehouse.org/trunk/djw/custom/ProductCatalog_custom/models.py. Here we put fields 'authors', 'isbn', 'size', so every store product would have it.

OneToOne field have one big advantage over ForeignKey - it is guaranteed to be only one such record. Also, that takes single SQL query to get all our products and their attributes, so we have a good performance of product listings.

Cart

From our previous experience, Cart itself can contain products and some meta information about those products. So, we initially developed cart structure that site developer could store this meta inforamation to CartItemSpecialAttribute?. Everything else is a very typical Cart, nothing really special. One note about taxes calculation: we know that in different countries there are different rules on calculating tax, and on applying float rounding rules. There are few configuration variables in settings/default.py which you can override either in project_settings.py or in settings.py

Plugins: Discount, Promotion, Payment, Shipment, Tax

Those are typical types of plugins. Since we can not guarantee that any one will be used in a typical store, we did not hardcoded to djw/core any of them. Instead, site developer encourage to use it from 'modules' section, or write own.

Plugins mean:

  • defined API between plugin and djw/core
  • configured by user

So, developer (or sysadmin) adds plugin (phisycally) to djw/modules, and site admin can use any of them, by configuring via djwarehouse administration interface.

All module variables are stored in database - so its easy for end user to configure them.

UserRequest

That module is made to perform time-delayed operations, for example we can register (add to User/Customer) only users which confirmed their identity by pressing link in EMail. Or do any other action which requires either time delay or delayed confirmation.