Moved some documentation to new places

docs/_sources/adding_the_fields.txt

@@ -1,23 +0,0 @@
-.. _adding_the_fields:
-
-=================================
-Adding the fields to the database
-=================================
-
-While Django will create the appropriate columns and tables if you configure Django Categories first, many times that is not possible. You could also reset the table, but you would loose all data in it. There is another way.
-
-Enter South
-***********
-
-`South <http://south.aeracode.org/>`_ is a Django application for managing database schema changes. South's default behavior is for managing permanent changes to a model's structure. In the case of dynamically adding a field or fields to a model, this doesn't work because you are not making the change permanent. And probably don't want to.
-
-Django Categories has a management command to create any missing fields. It requires South because it uses the South's API for making changes to databases. The management command is simple: ``python manage.py add_category_fields [app]``\ . If you do not include an app name, it will attempt to do all applications configured.
-
-Running this command several times will not hurt any data or cause any errors.
-
-Reconfiguring Fields
-********************
-
-You can make changes to the field configurations as long as they do not change the underlying database structure. For example, adding a ``related_name`` (see :ref:`registering_a_m2one_relationship`\ ) because it only affects Django code. Changing the name of the field, however, is a different matter.
-
-Django Categories provides a complementary management command to drop a field from the database (the field must still be in the configuration to do so): ``python manage.py drop_category_field app_name model_name field_name``

docs/_sources/custom_categories.txt

@@ -1,56 +0,0 @@
-.. _creating_custom_categories:
-
-==========================
-Creating Custom Categories
-==========================
-
-Django Categories isn't just for using a single category model. It allows you to create your own custom category-like models with as little or much customization as you need.
-
-Name only
-=========
-
-For many cases, you want a simple user-managed lookup table. You can do this with just a little bit of code. The resulting model will include name, slug and active fields and a hierarchical admin.
-
-#. Create a model that subclasses :py:class:`CategoryBase`
-
-   .. literalinclude:: code_examples/custom_categories1.py
-      :linenos:
-
-#. Create a subclass of CategoryBaseAdmin.
-
-   .. literalinclude:: code_examples/custom_categories2.py
-      :linenos:
-
-#. Register your model and custom model admin class.
-
-Name and other data
-===================
-
-Sometimes you need more functionality, such as extra metadata and custom functions. The :py:class:`Category` model in this package does this.
-
-#. Create a model that subclasses :py:class:`CategoryBase` as above.
-
-#. Add new fields to the model. The :py:class:`Category` model adds these extra fields.
-
-   .. literalinclude:: code_examples/custom_categories3.py
-      :linenos:
-
-#. Add new methods to the model. For example, the :py:class:`Category` model adds several new methods, including overriding the :py:meth:`save` method.
-
-   .. literalinclude:: code_examples/custom_categories4.py
-      :linenos:
-
-#. Alter :py:class:`Meta` or :py:class:`MPTTMeta` class. Either of these inner classes can be overridden, however your :py:class:`Meta` class should inherit :py:class:`CategoryBase.Meta`. Options for :py:class:`Meta` are in the `Django-MPTT docs <http://readthedocs.org/docs/django-mptt/en/latest/models.html#model-options>`_.
-
-   .. literalinclude:: code_examples/custom_categories5.py
-      :linenos:
-
-#. For the admin, you must create a form that subclasses :py:class:`CategoryBaseAdminForm` and at least sets the ``Meta.model`` attribute. You can also alter the form fields and cleaning methods, as :py:class:`Category` does.
-
-   .. literalinclude:: code_examples/custom_categories6.py
-      :linenos:
-
-#. Next you must subclass :py:class:`CategoryBaseAdmin` and assign the ``form`` attribute the form class created above. You can alter any other attributes as necessary.
-
-   .. literalinclude:: code_examples/custom_categories7.py
-      :linenos:

docs/_sources/registering_models.txt

@@ -1,139 +0,0 @@
-.. _registering_models:
-
-==================
-Registering Models
-==================
-
-
-Registering models in settings.py
-=================================
-
-It is nice to not have to modify the code of applications to add a relation to categories. You can therefore do all the registering in ``settings.py``\ . For example:
-
-.. code-block:: python
-	
-	CATEGORIES_SETTINGS = {
-	    'FK_REGISTRY': {
-	        'app.AModel': 'category',
-	        'app.MyModel': (
-	            'primary_category', 
-	            {'name': 'secondary_category', 'related_name': 'mymodel_sec_cat'}, )
-	    },
-	    'M2M_REGISTRY': {
-	        'app.BModel': 'categories',
-	        'app.MyModel': ('other_categories', 'more_categories', ),
-	    }
-	}
-
-The ``FK_REGISTRY`` is a dictionary whose keys are the model to which to add the new field(s). The value is a string or tuple of strings or dictionaries specifying the necessary information for each field. 
-
-The ``M2M_REGISTRY`` is a dictionary whose keys are the model to which to add the new field(s). The value is a string or tuple of strings specifying the necessary information for each field.
-
-
-Registering one Category field to model
-***************************************
-
-The simplest way is to specify the name of the field, such as:
-
-.. code-block:: python
-	
-	CATEGORIES_SETTINGS = {
-	    'FK_REGISTRY': {
-	        'app.AModel': 'category'
-	    }
-	}
-
-This is equivalent to adding the following the ``AModel`` of ``app``\ :
-
-.. code-block:: python
-	
-	category = models.ForeignKey(Category)
-
-
-If you want more control over the new field, you can use a dictionary and pass other ``ForeignKey`` options. The ``name`` key is required:
-
-.. code-block:: python
-	
-	CATEGORIES_SETTINGS = {
-	    'FK_REGISTRY': {
-	        'app.AModel': {'name': 'category', 'related_name': 'amodel_cats'}
-	    }
-	}
-
-This is equivalent to adding the following the ``AModel`` of ``app``\ :
-
-.. code-block:: python
-
-	category = models.ForeignKey(Category, related_name='amodel_cats')
-
-Registering two or more Category fields to a Model
-**************************************************
-
-When you want more than one relation to ``Category``\ , all but one of the fields must specify a ``related_name`` to avoid conflicts, like so:
-
-.. code-block:: python
-	
-	CATEGORIES_SETTINGS = {
-	    'FK_REGISTRY': {
-	        'app.MyModel': (
-	            'primary_category', 
-	            {'name': 'secondary_category', 'related_name': 'mymodel_sec_cat'}, )
-	    },
-
-Registering one or more Many-to-Many Category fields to a Model
-***************************************************************
-
-.. code-block:: python
-	
-	CATEGORIES_SETTINGS = {
-	    'M2M_REGISTRY': {
-	        'app.AModel': 'categories',
-	        'app.MyModel': (
-	            {'name': 'other_categories', 'related_name': 'other_cats'}, 
-	            {'name': 'more_categories', 'related_name': 'more_cats'}, 
-	        ),
-	    }
-	}
-
-.. _registering_a_m2one_relationship:
-
-Registering a many-to-one relationship
-======================================
-
-To create a many-to-one relationship (foreign key) between a model and Django Categories, you register your model with the ``register_fk`` function.
-
-.. py:function:: register_fk(model, field_name='category', extra_params={}])
-   
-   :param model: The Django Model to link to Django Categories
-   :param field_name: Optional name for the field **default:** category
-   :param extra_params: Optional dictionary of extra parameters passed to the ``ForeignKey`` class.
-
-Example, in your ``models.py``::
-
-	import categories
-	categories.register_fk(MyModel)
-
-If you want more than one field on a model you have to have some extra arguments::
-
-	import categories
-	categories.register_fk(MyModel, 'primary_category')
-	categories.register_fk(MyModel, 'secondary_category', {'related_name':'mymodel_sec_cat'})
-
-The ``extra_args`` allows you to specify the related_name of one of the fields so it doesn't clash.
-
-
-Registering a many-to-many relationship
-=======================================
-
-To create a many-to-many relationship between a model and Django Categories, you register your model with the ``register_m2m`` function.
-
-.. py:function:: register_m2m(model, field_name='categories', extra_params={}])
-   
-   :param model: The Django Model to link to Django Categories
-   :param field_name: Optional name for the field **default:** categories
-   :param extra_params: Optional dictionary of extra parameters passed to the ``ManyToManyField`` class.
-
-Example, in your ``models.py``::
-
-	import categories
-	categories.register_m2m(MyModel)

docs/_sources/usage.txt

@@ -1,62 +0,0 @@
-=============================
-Using categories in templates
-=============================
-
-
-Getting all items within a category
-===================================
-
-The :py:class:`Category` model automatically gets `reverse relationships <https://docs.djangoproject.com/en/1.3/topics/db/queries/#following-relationships-backward>`_ with all other models related to it.
-
-This allows you access to the related objects from the template without altering any views. For example, if you only had ``Entry`` models related to :py:class:`Category`, your ``categories/category_detail.html`` template could look like
-
-.. literalinclude:: usage_example_template.html
-   :language: django
-   :linenos:
-
-
-If you have ``related_name`` parameters to the configuration (see :ref:`registering_models`), then you would use ``category.related_name.all`` instead of ``category.relatedmodel_set.all``\ .
-
-
-Template Tags
-=============
-
-To use the template tags::
-
-	{% import category_tags %}
-
-
-``tree_info``
--------------
-
-Given a list of categories, iterates over the list, generating
-two-tuples of the current tree item and a ``dict`` containing
-information about the tree structure around the item, with the following
-keys:
-
-   ``'new_level'``
-      ``True`` if the current item is the start of a new level in
-      the tree, ``False`` otherwise.
-
-   ``'closed_levels'``
-      A list of levels which end after the current item. This will
-      be an empty list if the next item's level is the same as or
-      greater than the level of the current item.
-
-An optional argument can be provided to specify extra details about the
-structure which should appear in the ``dict``. This should be a
-comma-separated list of feature names. The valid feature names are:
-
-   ancestors
-      Adds a list of unicode representations of the ancestors of the
-      current node, in descending order (root node first, immediate
-      parent last), under the key ``'ancestors'``.
-
-      For example: given the sample tree below, the contents of the list
-      which would be available under the ``'ancestors'`` key are given
-      on the right::
-
-         Books                    ->  []
-            Sci-fi                ->  [u'Books']
-               Dystopian Futures  ->  [u'Books', u'Sci-fi']
-