Merge branch 'releases/0.2'

CHANGELOG.rst

@@ -2,34 +2,33 @@
 Changelog
 =========
 
-0.1
-~~~
+0.2 - 01 June 2012
+~~~~~~~~~~~~~~~~~~
 
-* Initial release - used in production by two major applications at Tangent but
-  still quite rough around the edges.  Many features were implemented directly
-  in the applications rather than using a feature from oscar.
-* Docs are a bit stale and need updating in 0.2
+Many components have been rewritten since 0.1 - Oscar is much more of a complete
+package now.  New features include:
 
-Roadmap
--------
+* Dashboard for managing catalogue, offers, stock, vouchers and more.  This includes
+  statistics pages to track performance.
 
-0.2
-~~~
+* Sample templates, CSS and JS to get a shop up and running in a minutes.  
+
+* Updated documentation.
 
-Currently a work-in-progress, estimated release date: May 2012.  It will feature:
+* Reworking of shipping methods.
 
-* Much better documentation, including recipes for common tasks
-* Refactoring of shipping methods
-* New dashboard functionality for product management, order management, customer services
-* New dynamic class loading
-* Lots more tests!
-* A fully styled sandbox shop based on Twitter's bootstrap.
+* Automatic up-selling on the basket page.  We now inform the user if they
+  partially quanlify for an offer.
 
-0.3
+The documentation still needs more work which we'll do over the next week or
+two.
+
+0.1
 ~~~
 
-* Rewrite of search app to use Solr and probably not Haystack
-* Much better support for variant products which aren't handled very well at the
-  moment.
-* Dashboard issue management
-* Better support for role-based permissions
+* Initial release - used in production by two major applications at Tangent but
+  still quite rough around the edges.  Many features were implemented directly
+  in the applications rather than using a feature from oscar.
+
+* Docs are a bit stale and need updating in 0.2
+

docs/source/design_decisions.rst

@@ -8,9 +8,9 @@ extended and customised to suit the domain at hand.  This is acheived in several
 Core models are abstract
 ------------------------
 
-Online shops can vary wildly, selling everything from turnips to concert tickets.  Trying
-to define a set of Django models capable for modelling all such scenarios is impossible -
-customisation is what matters.
+Online shops can vary wildly, selling everything from turnips to concert
+tickets.  Trying to define a set of Django models capable for modelling all such
+scenarios is impossible - customisation is what matters.
 
 One way to model your domain is to have enormous models that have fields for
 every possible variation; however, this is unwieldy and ugly.  
@@ -24,7 +24,7 @@ where all the fields are meaningful within any e-commerce domain.  Oscar then
 provides a mechanism for subclassing these models within your application so
 domain-specific fields can be added.
 
-Specifically, in each of oscar's apps, there is an ``abstract_models.py`` module which
+Specifically, in many of oscar's apps, there is an ``abstract_models.py`` module which
 defines these abstract classes.  There is also an accompanying ``models.py`` which provides an
 empty but concrete implementation of each abstract model.
 
@@ -32,27 +32,30 @@ Classes are loaded dynamically
 ------------------------------
 
 To enable sub-apps to be overridden, oscar classes are loading generically
-using a special ``import_module`` function.  This looks at the
+using a special ``get_class`` function.  This looks at the
 ``INSTALLED_APPS`` tuple to determine the appropriate app to load a class from.
 
-Within oscar itself, classes are imported using a special ``import_module`` function
-which determines which app to load the specified classes from.  Sample usage is::
+Sample usage::
 
-    import_module('product.models', ['Item', 'ItemClass'], locals())
+    from oscar.core.loading import get_class
+
+    Repository = get_class('shipping.repository', 'Repository')
     
-This will load the ``Item`` and ``ItemClass`` classes into the local namespace.  It is
-a replacement for the usual::
+This is a replacement for the usual::
+
+    from oscar.apps.shipping.repository import Repository
 
-    from oscar.product.models import Item, ItemClass
+It is effectively an extension of Django's ``django.db.models.get_model``
+function to work with arbitrary classes.
     
-The ``import_module`` looks through your ``INSTALLED_APPS`` for a matching module to
+The ``get_class`` function looks through your ``INSTALLED_APPS`` for a matching module to
 the one specified and will load the classes from there.  If the matching module is
 not from oscar's core, then it will also fall back to the equivalent module if the
 class cannot be found.
 
-This structure enables a project to create a local ``product.models`` module and 
-subclass and extend the core models from ``oscar.app.product.models``.  When Oscar
-tries to load the ``Item`` class, it will load the one from your local project.
+This structure enables a project to create a local ``shipping.repository`` module and 
+subclass and extend the classes from ``oscar.app.shipping.repository``.  When Oscar
+tries to load the ``Repository`` class, it will load the one from your local project.
 
 All views are class-based
 -------------------------

docs/source/getting_help.rst

@@ -0,0 +1,15 @@
+============
+Getting help
+============
+
+If you're stuck with a problem, try checking the `Google Groups archive`_ to see if
+someone has encountered it before.  If not, then try asking on the mailing list
+django-oscar@googlegroups.com.  If it's a common question, then we'll write up
+the solution as a recipe.
+
+.. _`Google Groups archive`: https://groups.google.com/forum/?fromgroups#!forum/django-oscar
+
+If you find a bug, please report it in the `Github issue tracker`_
+
+.. _`Github issue tracker`: https://github.com/tangentlabs/django-oscar/issues
+

docs/source/getting_started.rst

@@ -113,7 +113,7 @@ Install using Tangent's boilerplate django project
 The easiest way to get started is to use Tangent's `template django project`_
 although it is tailored to an Agency structure which may not suit everyone.
 
-.. `template django project`: https://github.com/tangentlabs/tangent-django-boilerplate
+.. _`template django project`: https://github.com/tangentlabs/tangent-django-boilerplate
 
 Set up a virtualenv, and create a new project using the ``startproject``
 management command::
@@ -124,7 +124,7 @@ management command::
         --template=https://github.com/tangentlabs/tangent-django-boilerplate/zipball/master 
 
 This will create a folder ``frobshop`` which is an entire templated project that
-follows Tangent's conventions.  The structure is:
+follows Tangent's conventions.  The structure is::
 
     frobshop/
         docs/

docs/source/index.rst

@@ -53,6 +53,7 @@ ipads.  The `source is on Github`_.
    getting_started
    key_questions
    recipes
+   getting_help
    design_decisions
    reference
    contributing

docs/source/recipes/how_to_configure_shipping.rst

@@ -32,7 +32,7 @@ Set a custom shipping methods
 -----------------------------
 
 To apply your domain logic for shipping, you will need to override
-the default repository class (see :doc:`how_to_override_a_class`) and alter
+the default repository class (see :doc:`recipes/how_to_override_a_class`) and alter
 the implementation of the ``get_shipping_methods`` method.  This method
 should return a list of "shipping method" classes already instantiated
 and holding a reference to the basket instance.