diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/add_ons.txt | 16 | ||||
| -rw-r--r-- | docs/contributing.txt | 41 | ||||
| -rw-r--r-- | docs/databases.txt | 162 | ||||
| -rw-r--r-- | docs/db-api.txt | 6 | ||||
| -rw-r--r-- | docs/distributions.txt | 2 | ||||
| -rw-r--r-- | docs/django-admin.txt | 2 | ||||
| -rw-r--r-- | docs/fastcgi.txt | 11 | ||||
| -rw-r--r-- | docs/forms.txt | 21 | ||||
| -rw-r--r-- | docs/i18n.txt | 11 | ||||
| -rw-r--r-- | docs/model-api.txt | 4 | ||||
| -rw-r--r-- | docs/release_notes_0.96.txt | 264 | ||||
| -rw-r--r-- | docs/serialization.txt | 3 | ||||
| -rw-r--r-- | docs/settings.txt | 10 | ||||
| -rw-r--r-- | docs/testing.txt | 6 |
14 files changed, 538 insertions, 21 deletions
diff --git a/docs/add_ons.txt b/docs/add_ons.txt index 1756fe5720..8f47847e3e 100644 --- a/docs/add_ons.txt +++ b/docs/add_ons.txt @@ -1,6 +1,6 @@ -===================== -The "contrib" add-ons -===================== +============================ +The "django.contrib" add-ons +============================ Django aims to follow Python's `"batteries included" philosophy`_. It ships with a variety of extra, optional tools that solve common Web-development @@ -153,12 +153,16 @@ markup A collection of template filters that implement these common markup languages: - * Textile - * Markdown - * ReST (ReStructured Text) + * `Textile`_ + * `Markdown`_ + * `ReST (ReStructured Text)`_ For documentation, read the source code in django/contrib/markup/templatetags/markup.py. +.. _Textile: http://en.wikipedia.org/wiki/Textile_%28markup_language%29 +.. _Markdown: http://en.wikipedia.org/wiki/Markdown +.. _ReST (ReStructured Text): http://en.wikipedia.org/wiki/ReStructuredText + redirects ========= diff --git a/docs/contributing.txt b/docs/contributing.txt index 6b2b64f672..1d2b635b76 100644 --- a/docs/contributing.txt +++ b/docs/contributing.txt @@ -195,7 +195,7 @@ The second part of this workflow involves a set of flags the describe what the ticket has or needs in order to be "ready for checkin": "Has patch" - The means the ticket has an associated patch_. These will be + This means the ticket has an associated patch_. These will be reviewed to see if the patch is "good". "Needs documentation" @@ -212,6 +212,33 @@ ticket has or needs in order to be "ready for checkin": ready for checkin. This could mean the patch no longer applies cleanly, or that the code doesn't live up to our standards. +A ticket can be resolved in a number of ways: + + "fixed" + Used by one of the core developers once a patch has been rolled into + Django and the issue is fixed. + + "invalid" + Used if the ticket is found to be incorrect or a user error. + + "wontfix" + Used when a core developer decides that this request is not + appropriate for consideration in Django. This is usually chosen after + discussion in the ``django-developers`` mailing list, and you should + feel free to join in when it's something you care about. + + "duplicate" + Used when another ticket covers the same issue. By closing duplicate + tickets, we keep all the discussion in one place, which helps everyone. + + "worksforme" + Used when the triage team is unable to replicate the original bug. + +If you believe that the ticket was closed in error -- because you're +still having the issue, or it's popped up somewhere else, or the triagers have +-- made a mistake, please reopen the ticket and tell us why. Please do not +reopen tickets that have been marked as "wontfix" by core developers. + .. _required details: `Reporting bugs`_ .. _good patch: `Patch style`_ .. _patch: `Submitting patches`_ @@ -276,9 +303,11 @@ Please follow these coding standards when writing code for inclusion in Django: def my_view(req, foo): # ... - * Please don't put your name in the code. While we appreciate all - contributions to Django, our policy is not to publish individual - developer names in code -- for instance, at the top of Python modules. + * Please don't put your name in the code you contribute. Our policy is to + keep contributors' names in the ``AUTHORS`` file distributed with Django + -- not scattered throughout the codebase itself. Feel free to include a + change to the ``AUTHORS`` file in your patch if you make more than a + single trivial change. Committing code =============== @@ -498,12 +527,12 @@ sure all other lines are commented:: # http://code.djangoproject.com/svn/django/trunk/ # /path/to/trunk - + # <branch> is a svn checkout of: # http://code.djangoproject.com/svn/django/branches/<branch>/ # #/path/to/<branch> - + # On windows a path may look like this: # C:/path/to/<branch> diff --git a/docs/databases.txt b/docs/databases.txt new file mode 100644 index 0000000000..3545b58d47 --- /dev/null +++ b/docs/databases.txt @@ -0,0 +1,162 @@ +=============================== +Notes about supported databases +=============================== + +Django attempts to support as many features as possible on all database +backends. However, not all database backends are alike, and we've had to make +design decisions on which features to support and which assumptions we can make +safely. + +This file describes some of the features that might be relevant to Django +usage. Of course, it is not intended as a replacement for server-specific +documentation or reference manuals. + +MySQL notes +=========== + +Django expects the database to support transactions, referential integrity, +and Unicode support (UTF-8 encoding). Fortunately, MySQL_ has all these +features as available as far back as 3.23. While it may be possible to use +3.23 or 4.0, you'll probably have less trouble if you use 4.1 or 5.0. + +MySQL 4.1 +--------- + +`MySQL 4.1`_ has greatly improved support for character sets. It is possible to +set different default character sets on the database, table, and column. +Previous versions have only a server-wide character set setting. It's also the +first version where the character set can be changed on the fly. 4.1 also has +support for views, but Django currently doesn't use views. + +MySQL 5.0 +--------- + +`MySQL 5.0`_ adds the ``information_schema`` database, which contains detailed +data on all database schema. Django's ``inspectdb`` feature uses this +``information_schema`` if it's available. 5.0 also has support for stored +procedures, but Django currently doesn't use stored procedures. + +.. _MySQL: http://www.mysql.com/ +.. _MySQL 4.1: http://dev.mysql.com/doc/refman/4.1/en/index.html +.. _MySQL 5.0: http://dev.mysql.com/doc/refman/5.0/en/index.html + +Storage engines +--------------- + +MySQL has several `storage engines`_ (previously called table types). You can +change the default storage engine in the server configuration. + +The default engine is MyISAM_. The main drawback of MyISAM is that it doesn't +currently support transactions or foreign keys. On the plus side, it's +currently the only engine that supports full-text indexing and searching. + +The InnoDB_ engine is fully transactional and supports foreign key references. + +The BDB_ engine, like InnoDB, is also fully transactional and supports foreign +key references. However, its use seems to be deprecated. + +`Other storage engines`_, including SolidDB_ and Falcon_, are on the horizon. +For now, InnoDB is probably your best choice. + +.. _storage engines: http://dev.mysql.com/doc/refman/5.0/en/storage-engines.html +.. _MyISAM: http://dev.mysql.com/doc/refman/5.0/en/myisam-storage-engine.html +.. _BDB: http://dev.mysql.com/doc/refman/5.0/en/bdb-storage-engine.html +.. _InnoDB: http://dev.mysql.com/doc/refman/5.0/en/innodb.html +.. _Other storage engines: http://dev.mysql.com/doc/refman/5.1/en/storage-engines-other.html +.. _SolidDB: http://forge.mysql.com/projects/view.php?id=139 +.. _Falcon: http://dev.mysql.com/doc/falcon/en/index.html + +MySQLdb +------- + +`MySQLdb`_ is the Python interface to MySQL. 1.2.1 is the first version that +has support for MySQL 4.1 and newer. If you are trying to use an older version +of MySQL, then 1.2.0 *might* work for you. + +.. _MySQLdb: http://sourceforge.net/projects/mysql-python + +Creating your database +---------------------- + +You can `create your database`_ using the command-line tools and this SQL:: + + CREATE DATABASE <dbname> CHARACTER SET utf8; + +This ensures all tables and columns will use UTF-8 by default. + +.. _create your database: http://dev.mysql.com/doc/refman/5.0/en/create-database.html + +Connecting to the database +-------------------------- + +Refer to the `settings documentation`_. + +Connection settings are used in this order: + + 1. ``DATABASE_OPTIONS`` + 2. ``DATABASE_NAME``, ``DATABASE_USER``, ``DATABASE_PASSWORD``, ``DATABASE_HOST``, + ``DATABASE_PORT`` + 3. MySQL option files. + +In other words, if you set the name of the database in ``DATABASE_OPTIONS``, +this will take precedence over ``DATABASE_NAME``, which would override +anything in a `MySQL option file`_. + +Here's a sample configuration which uses a MySQL option file:: + + # settings.py + DATABASE_ENGINE = "mysql" + DATABASE_OPTIONS = { + 'read_default_file': '/path/to/my.cnf', + } + + # my.cnf + [client] + database = DATABASE_NAME + user = DATABASE_USER + passwd = DATABASE_PASSWORD + default-character-set = utf8 + +Several other MySQLdb connection options may be useful, such as ``ssl``, +``use_unicode``, ``init_command``, and ``sql_mode``. Consult the +`MySQLdb documentation`_ for more details. + +.. _settings documentation: http://www.djangoproject.com/documentation/settings/#database-engine +.. _MySQL option file: http://dev.mysql.com/doc/refman/5.0/en/option-files.html +.. _MySQLdb documentation: http://mysql-python.sourceforge.net/ + +Creating your tables +-------------------- + +When Django generates the schema, it doesn't specify a storage engine, so +tables will be created with whatever default storage engine your database +server is configured for. The easiest solution is to set your database server's +default storage engine to the desired engine. + +If you're using a hosting service and can't change your server's default +storage engine, you have a couple of options. + + * After the tables are created, execute an ``ALTER TABLE`` statement to + convert a table to a new storage engine (such as InnoDB):: + + ALTER TABLE <tablename> ENGINE=INNODB; + + This can be tedious if you have a lot of tables. + + * Another option is to use the ``init_command`` option for MySQLdb prior to + creating your tables:: + + DATABASE_OPTIONS = { + # ... + "init_command": "SET storage_engine=INNODB", + # ... + } + + This sets the default storage engine upon connecting to the database. + After your tables have been created, you should remove this option. + + * Another method for changing the storage engine is described in + AlterModelOnSyncDB_. + +.. _AlterModelOnSyncDB: http://code.djangoproject.com/wiki/AlterModelOnSyncDB + diff --git a/docs/db-api.txt b/docs/db-api.txt index 20a319740e..64db3def96 100644 --- a/docs/db-api.txt +++ b/docs/db-api.txt @@ -6,7 +6,7 @@ Once you've created your `data models`_, Django automatically gives you a database-abstraction API that lets you create, retrieve, update and delete objects. This document explains that API. -.. _`data models`: http://www.djangoproject.com/documentation/model_api/ +.. _`data models`: ../model_api/ Throughout this reference, we'll refer to the following models, which comprise a weblog application:: @@ -85,7 +85,7 @@ There's no way to tell what the value of an ID will be before you call unless you explicitly specify ``primary_key=True`` on a field. See the `AutoField documentation`_.) -.. _AutoField documentation: http://www.djangoproject.com/documentation/model_api/#autofield +.. _AutoField documentation: ../model_api/#autofield Explicitly specifying auto-primary-key values ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1801,4 +1801,4 @@ interface to your database. You can access your database via other tools, programming languages or database frameworks; there's nothing Django-specific about your database. -.. _Executing custom SQL: http://www.djangoproject.com/documentation/model_api/#executing-custom-sql +.. _Executing custom SQL: ../model_api/#executing-custom-sql diff --git a/docs/distributions.txt b/docs/distributions.txt index a77d3a1959..63206c535e 100644 --- a/docs/distributions.txt +++ b/docs/distributions.txt @@ -57,7 +57,7 @@ Gentoo ------ A Django build is available for `Gentoo Linux`_, and is based on Django 0.95.1. -The `current Gentoo build`_ can be installed by typing ``emerge Django``. +The `current Gentoo build`_ can be installed by typing ``emerge django``. .. _Gentoo Linux: http://www.gentoo.org/ .. _current Gentoo build: http://packages.gentoo.org/packages/?category=dev-python;name=django diff --git a/docs/django-admin.txt b/docs/django-admin.txt index 371c44e010..ef1d73cdbd 100644 --- a/docs/django-admin.txt +++ b/docs/django-admin.txt @@ -216,7 +216,7 @@ installation will be aborted, and any data installed in the call to ``loaddata`` will be removed from the database. The fixtures that are named can include directory components. These -directories will be inluded in the search path. For example:: +directories will be included in the search path. For example:: django-admin.py loaddata foo/bar/mydata.json diff --git a/docs/fastcgi.txt b/docs/fastcgi.txt index 1efeaf09cf..5ecaac8666 100644 --- a/docs/fastcgi.txt +++ b/docs/fastcgi.txt @@ -304,3 +304,14 @@ If you have access to a command shell on a Unix system, you can accomplish this easily by using the ``touch`` command:: touch mysite.fcgi + +Serving admin media files +========================= + +Regardless of the server and configuration you eventually decide to use, you will +also need to give some thought to how to serve the admin media files. The +advice given in the modpython_ documentation is also applicable in the setups +detailed above. + +.. _modpython: ../modpython/#serving-the-admin-files + diff --git a/docs/forms.txt b/docs/forms.txt index 8c40eeb997..f76f6d27ef 100644 --- a/docs/forms.txt +++ b/docs/forms.txt @@ -417,6 +417,27 @@ Here's a simple function that might drive the above form:: form = forms.FormWrapper(manipulator, new_data, errors) return render_to_response('contact_form.html', {'form': form}) +Implementing ``flatten_data`` for custom manipulators +------------------------------------------------------ + +It is possible (although rarely needed) to replace the default automatically +created manipulators on a model with your own custom manipulators. If you do +this and you are intending to use those models in generic views, you should +also define a ``flatten_data`` method in any ``ChangeManipulator`` replacement. +This should act like the default ``flatten_data`` and return a dictionary +mapping field names to their values, like so:: + + def flatten_data(self): + obj = self.original_object + return dict( + from = obj.from, + subject = obj.subject, + ... + ) + +In this way, your new change manipulator will act exactly like the default +version. + ``FileField`` and ``ImageField`` special cases ============================================== diff --git a/docs/i18n.txt b/docs/i18n.txt index d7f5db6861..4a05e53ddf 100644 --- a/docs/i18n.txt +++ b/docs/i18n.txt @@ -282,6 +282,17 @@ How to create language files Once you've tagged your strings for later translation, you need to write (or obtain) the language translations themselves. Here's how that works. +.. admonition:: Locale restrictions + + Django does not support localizing your application into a locale for + which Django itself has not been translated. In this case, it will ignore + your translation files. If you were to try this and Django supported it, + you would inevitably see a mixture of translated strings (from your + application) and English strings (from Django itself). If you want to + support a locale for your application that is not already part of + Django, you'll need to make at least a minimal translation of the Django + core. + Message files ------------- diff --git a/docs/model-api.txt b/docs/model-api.txt index 1e7f69903d..26686b02fe 100644 --- a/docs/model-api.txt +++ b/docs/model-api.txt @@ -1216,6 +1216,10 @@ screen via ``<script src="">`` tags. This can be used to tweak a given type of admin page in JavaScript or to provide "quick links" to fill in default values for certain fields. +If you use relative URLs -- URLs that don't start with ``http://`` or ``/`` -- +then the admin site will automatically prefix these links with +``settings.ADMIN_MEDIA_PREFIX``. + ``list_display`` ---------------- diff --git a/docs/release_notes_0.96.txt b/docs/release_notes_0.96.txt new file mode 100644 index 0000000000..37f4034aa5 --- /dev/null +++ b/docs/release_notes_0.96.txt @@ -0,0 +1,264 @@ +================================= +Django version 0.96 release notes +================================= + +Welcome to Django 0.96! + +The primary goal for 0.96 is a cleanup and stabilization of the features +introduced in 0.95. There have been a few small `backwards-incompatible +changes`_ since 0.95, but the upgrade process should be fairly simple +and should not require major changes to existing applications. + +However, we're also releasing 0.96 now because we have a set of +backwards-incompatible changes scheduled for the near future. Once +completed, they will involve some code changes for application +developers, so we recommend that you stick with Django 0.96 until the +next official release; then you'll be able to upgrade in one step +instead of needing to make incremental changes to keep up with the +development version of Django. + +What's new in 0.96? +=================== + +This revision represents over a thousand source commits and over four hundred +bug fixes, so we can't possibly catalog all the changes. Here, we describe the +most notable changes in this release. + +New forms library +----------------- + +``django.newforms`` is Django's new form-handling library. It's a +replacement for ``django.forms``, the old form/manipulator/validation +framework. Both APIs are available in 0.96, but over the next two +releases we plan to switch completely to the new forms system, and +deprecate and remove the old system. + +There are three elements to this transition: + + * We've copied the current ``django.forms`` to + ``django.oldforms``. This allows you to upgrade your code *now* + rather than waiting for the backwards-incompatible change and + rushing to fix your code after the fact. Just change your + import statements like this:: + + from django import forms # 0.95-style + from django import oldforms as forms # 0.96-style + + * The next official release of Django will move the current + ``django.newforms`` to ``django.forms``. This will be a + backwards-incompatible change, and anyone still using the old + version of ``django.forms`` at that time will need to change + their import statements as described above. + + * The next release after that will completely remove + ``django.oldforms``. + +Although the ``newforms`` library will continue to evolve, it's ready for use +for most common cases. We recommend that anyone new to form handling skip the +old forms system and start with the new. + +For more information about ``django.newforms``, read the `newforms +documentation`_. + +.. _newforms documentation: ../newforms/ + +URLconf improvements +-------------------- + +You can now use any callable as the callback in URLconfs (previously, only +strings that referred to callables were allowed). This allows a much more +natural use of URLconfs. For example, this URLconf:: + + from django.conf.urls.defaults import * + + urlpatterns = patterns('', + ('^myview/$', 'mysite.myapp.views.myview') + ) + +can now be rewritten as:: + + from django.conf.urls.defaults import * + from mysite.myapp.views import myview + + urlpatterns = patterns('', + ('^myview/$', myview) + ) + +One useful application of this can be seen when using decorators; this +change allows you to apply decorators to views *in your +URLconf*. Thus, you can make a generic view require login very +easily:: + + from django.conf.urls.defaults import * + from django.contrib.auth.decorators import login_required + from django.views.generic.list_detail import object_list + from mysite.myapp.models import MyModel + + info = { + "queryset" : MyModel.objects.all(), + } + + urlpatterns = patterns('', + ('^myview/$', login_required(object_list), info) + ) + +Note that both syntaxes (strings and callables) are valid, and will continue to +be valid for the foreseeable future. + +The test framework +------------------ + +Django now includes a test framework so you can start transmuting fear into +boredom (with apologies to Kent Beck). You can write tests based on doctest_ +or unittest_ and test your views with a simple test client. + +There is also new support for "fixtures" -- initial data, stored in any of the +supported `serialization formats`_, that will be loaded into your database at the +start of your tests. This makes testing with real data much easier. + +See `the testing documentation`_ for the full details. + +.. _doctest: http://docs.python.org/lib/module-doctest.html +.. _unittest: http://docs.python.org/lib/module-unittest.html +.. _the testing documentation: ../testing/ +.. _serialization formats: ../serialization/ + +Improvements to the admin interface +----------------------------------- + +A small change, but a very nice one: dedicated views for adding and +updating users have been added to the admin interface, so you no +longer need to worry about working with hashed passwords in the admin. + +Backwards-incompatible changes +============================== + +The following changes may require you to update your code when you switch from +0.95 to 0.96: + +`MySQLdb` version requirement +----------------------------- + +Due to a bug in older versions of the `MySQLdb` Python module (which +Django uses to connect to MySQL databases), Django's MySQL backend now +requires version 1.2.1p2 or higher of `MySQLdb`, and will raise +exceptions if you attempt to use an older version. + +If you're currently unable to upgrade your copy of `MySQLdb` to meet +this requirement, a separate, backwards-compatible backend, called +"mysql_old", has been added to Django. To use this backend, change +the ``DATABASE_ENGINE`` setting in your Django settings file from +this:: + + DATABASE_ENGINE = "mysql" + +to this:: + + DATABASE_ENGINE = "mysql_old" + +However, we strongly encourage MySQL users to upgrade to a more recent +version of `MySQLdb` as soon as possible, The "mysql_old" backend is +provided only to ease this transition, and is considered deprecated; +aside from any necessary security fixes, it will not be actively +maintained, and it will be removed in a future release of Django. + +Also, note that some features, like the new ``DATABASE_OPTIONS`` +setting (see the `databases documentation`_ for details), are only +available on the "mysql" backend, and will not be made available for +"mysql_old". + +.. _databases: ../databases/ + +Database constraint names changed +--------------------------------- + +The format of the constraint names Django generates for foreign key +references have changed slightly. These names are generally only used +when it is not possible to put the reference directly on the affected +column, so they is not always visible. + +The effect of this change is that running ``manage.py reset`` and +similar commands against an existing database may generate SQL with +the new form of constraint name, while the database itself contains +constraints named in the old form; this will cause the database server +to raise an error message about modifying non-existent constraints. + +If you need to work around this, there are two methods available: + + 1. Redirect the output of ``manage.py`` to a file, and edit the + generated SQL to use the correct constraint names before + executing it. + + 2. Examine the output of ``manage.py sqlall`` to see the new-style + constraint names, and use that as a guide to rename existing + constraints in your database. + +Names changes in ``manage.py`` +------------------------------ + +A few of the options to ``manage.py`` have changed with the addition of fixture +support: + + * There are new ``dumpdata`` and ``loaddata`` commands which, as + you might expect, will dump and load data to/from the + database. These commands can operate against any of Django's + supported serialization formats. + + * The ``sqlinitialdata`` command has been renamed to ``sqlcustom`` to + emphasize that ``loaddata`` should be used for data (and ``sqlcustom`` for + other custom SQL -- views, stored procedures, etc.). + + * The vestigial ``install`` command has been removed. Use ``syncdb``. + +Backslash escaping changed +-------------------------- + +The Django database API now escapes backslashes given as query parameters. If +you have any database API code that matches backslashes, and it was working before +(despite the lack of escaping), you'll have to change your code to "unescape" the +slashes one level. + +For example, this used to work:: + + # Find text containing a single backslash + MyModel.objects.filter(text__contains='\\\\') + +The above is now incorrect, and should be rewritten as:: + + # Find text containing a single backslash + MyModel.objects.filter(text__contains='\\') + +Removed ENABLE_PSYCO setting +---------------------------- + +The ``ENABLE_PSYCO`` setting no longer exists. If your settings file includes +``ENABLE_PSYCO`` it will have no effect; to use Psyco, we recommend +writing a middleware class to activate it. + +.. _psyco: http://psyco.sourceforge.net/ + +Thanks +====== + +Since 0.95, a number of people have stepped forward and taken a major +new role in Django's development. We'd like to thank these people for +all their hard work: + + * Russell Keith-Magee and Malcolm Tredinnick for their major code + contributions. This release wouldn't have been possible without them. + + * Our new release manager, James Bennett, for his work in getting out + 0.95.1, 0.96, and (hopefully) future release. + + * Our ticket managers Chris Beaven (aka SmileyChris), Simon Greenhill, + Michael Radziej, and Gary Wilson. They agreed to take on the monumental + task of wrangling our tickets into nicely cataloged submission. Figuring + out what to work on is now about a million times easier; thanks again, + guys. + + * Everyone who submitted a bug report, patch or ticket comment. We can't + possibly thank everyone by name -- over 200 developers submitted patches + that went into 0.96 -- but everyone who's contributed to Django is listed + in AUTHORS_. + +.. _AUTHORS: http://code.djangoproject.com/browser/django/trunk/AUTHORS
\ No newline at end of file diff --git a/docs/serialization.txt b/docs/serialization.txt index aee1b9a3bb..48ab46f0f9 100644 --- a/docs/serialization.txt +++ b/docs/serialization.txt @@ -31,7 +31,8 @@ but it'll almost always be a QuerySet). You can also use a serializer object directly:: - xml_serializer = serializers.get_serializer("xml") + XMLSerializer = serializers.get_serializer("xml") + xml_serializer = XMLSerializer() xml_serializer.serialize(queryset) data = xml_serializer.getvalue() diff --git a/docs/settings.txt b/docs/settings.txt index b2ca11240a..6f85e312c0 100644 --- a/docs/settings.txt +++ b/docs/settings.txt @@ -162,10 +162,13 @@ a model object and return its URL. This is a way of overriding ``get_absolute_url()`` methods on a per-installation basis. Example:: ABSOLUTE_URL_OVERRIDES = { - 'blogs.Weblog': lambda o: "/blogs/%s/" % o.slug, - 'news.Story': lambda o: "/stories/%s/%s/" % (o.pub_year, o.slug), + 'blogs.weblog': lambda o: "/blogs/%s/" % o.slug, + 'news.story': lambda o: "/stories/%s/%s/" % (o.pub_year, o.slug), } +Note that the model name used in this setting should be all lower-case, regardless +of the case of the actual model class name. + ADMIN_FOR --------- @@ -242,7 +245,8 @@ DATABASE_ENGINE Default: ``''`` (Empty string) Which database backend to use. Either ``'postgresql_psycopg2'``, -``'postgresql'``, ``'mysql'``, ``'sqlite3'`` or ``'ado_mssql'``. +``'postgresql'``, ``'mysql'``, ``'mysql_old'``, ``'sqlite3'`` or +``'ado_mssql'``. DATABASE_HOST ------------- diff --git a/docs/testing.txt b/docs/testing.txt index f7fd402502..a67c907f6b 100644 --- a/docs/testing.txt +++ b/docs/testing.txt @@ -227,6 +227,12 @@ can be invoked on the ``Client`` instance. The key-value pairs in the data dictionary will be encoded as a multipart message and used to create the POST data payload. + To submit multiple values for a given key (for example, to specify + the selections for a multiple selection list), provide the values as a + list or tuple for the required key. For example, a data dictionary of + ``{'choices': ('a','b','d')}`` would submit three selected rows for the + field named ``choices``. + Submitting files is a special case. To POST a file, you need only provide the file field name as a key, and a file handle to the file you wish to upload as a value. The Test Client will populate the two POST fields (i.e., |