From 98e6ab0afc5ad56f4697da8925484c49c5e55657 Mon Sep 17 00:00:00 2001 From: Honza Král Date: Thu, 18 Jun 2009 01:37:18 +0000 Subject: [soc2009/model-validation] merged to trunk at r11032 git-svn-id: http://code.djangoproject.com/svn/django/branches/soc2009/model-validation@11038 bcc190cf-cafb-0310-a4f2-bffc1f526a37 --- docs/ref/files/storage.txt | 4 +-- docs/ref/generic-views.txt | 72 ++++++++----------------------------------- docs/ref/index.txt | 1 + docs/ref/models/fields.txt | 30 ++++++++++++------ docs/ref/models/querysets.txt | 2 ++ 5 files changed, 37 insertions(+), 72 deletions(-) (limited to 'docs/ref') diff --git a/docs/ref/files/storage.txt b/docs/ref/files/storage.txt index 0ca577059e..c8aafa8626 100644 --- a/docs/ref/files/storage.txt +++ b/docs/ref/files/storage.txt @@ -43,8 +43,8 @@ modify the filename as necessary to get a unique name. The actual name of the stored file will be returned. The ``content`` argument must be an instance of -:class:`django.db.files.File` or of a subclass of -:class:`~django.db.files.File`. +:class:`django.core.files.File` or of a subclass of +:class:`~django.core.files.File`. ``Storage.delete(name)`` ~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/docs/ref/generic-views.txt b/docs/ref/generic-views.txt index 427ef91090..4752a705a0 100644 --- a/docs/ref/generic-views.txt +++ b/docs/ref/generic-views.txt @@ -9,67 +9,18 @@ again and again. In Django, the most common of these patterns have been abstracted into "generic views" that let you quickly provide common views of an object without actually needing to write any Python code. -Django's generic views contain the following: +A general introduction to generic views can be found in the :ref:`topic guide +`. - * A set of views for doing list/detail interfaces. - - * A set of views for year/month/day archive pages and associated - detail and "latest" pages (for example, the Django weblog's year_, - month_, day_, detail_, and latest_ pages). - - * A set of views for creating, editing, and deleting objects. - -.. _year: http://www.djangoproject.com/weblog/2005/ -.. _month: http://www.djangoproject.com/weblog/2005/jul/ -.. _day: http://www.djangoproject.com/weblog/2005/jul/20/ -.. _detail: http://www.djangoproject.com/weblog/2005/jul/20/autoreload/ -.. _latest: http://www.djangoproject.com/weblog/ - -All of these views are used by creating configuration dictionaries in -your URLconf files and passing those dictionaries as the third member of the -URLconf tuple for a given pattern. For example, here's the URLconf for the -simple weblog app that drives the blog on djangoproject.com:: - - from django.conf.urls.defaults import * - from django_website.apps.blog.models import Entry - - info_dict = { - 'queryset': Entry.objects.all(), - 'date_field': 'pub_date', - } - - urlpatterns = patterns('django.views.generic.date_based', - (r'^(?P\d{4})/(?P[a-z]{3})/(?P\w{1,2})/(?P[-\w]+)/$', 'object_detail', info_dict), - (r'^(?P\d{4})/(?P[a-z]{3})/(?P\w{1,2})/$', 'archive_day', info_dict), - (r'^(?P\d{4})/(?P[a-z]{3})/$', 'archive_month', info_dict), - (r'^(?P\d{4})/$', 'archive_year', info_dict), - (r'^$', 'archive_index', info_dict), - ) - -As you can see, this URLconf defines a few options in ``info_dict``. -``'queryset'`` gives the generic view a ``QuerySet`` of objects to use (in this -case, all of the ``Entry`` objects) and tells the generic view which model is -being used. - -Documentation of each generic view follows, along with a list of all keyword -arguments that a generic view expects. Remember that as in the example above, -arguments may either come from the URL pattern (as ``month``, ``day``, -``year``, etc. do above) or from the additional-information dictionary (as for -``queryset``, ``date_field``, etc.). +This reference contains details of Django's built-in generic views, along with +a list of all keyword arguments that a generic view expects. Remember that +arguments may either come from the URL pattern or from the ``extra_context`` +additional-information dictionary. Most generic views require the ``queryset`` key, which is a ``QuerySet`` instance; see :ref:`topics-db-queries` for more information about ``QuerySet`` objects. -Most views also take an optional ``extra_context`` dictionary that you can use -to pass any auxiliary information you wish to the view. The values in the -``extra_context`` dictionary can be either functions (or other callables) or -other objects. Functions are evaluated just before they are passed to the -template. However, note that QuerySets retrieve and cache their data when they -are first evaluated, so if you want to pass in a QuerySet via -``extra_context`` that is always fresh you need to wrap it in a function or -lambda that returns the QuerySet. - "Simple" generic views ====================== @@ -801,12 +752,12 @@ specify the page number in the URL in one of two ways: /objects/?page=3 - * To loop over all the available page numbers, use the ``page_range`` - variable. You can iterate over the list provided by ``page_range`` + * To loop over all the available page numbers, use the ``page_range`` + variable. You can iterate over the list provided by ``page_range`` to create a link to every page of results. These values and lists are 1-based, not 0-based, so the first page would be -represented as page ``1``. +represented as page ``1``. For more on pagination, read the :ref:`pagination documentation `. @@ -818,7 +769,7 @@ As a special case, you are also permitted to use ``last`` as a value for /objects/?page=last -This allows you to access the final page of results without first having to +This allows you to access the final page of results without first having to determine how many pages there are. Note that ``page`` *must* be either a valid page number or the value ``last``; @@ -909,7 +860,7 @@ library ` to build and display the form. **Description:** A page that displays a form for creating an object, redisplaying the form with -validation errors (if there are any) and saving the object. +validation errors (if there are any) and saving the object. **Required arguments:** @@ -1137,3 +1088,4 @@ In addition to ``extra_context``, the template's context will be: variable's name depends on the ``template_object_name`` parameter, which is ``'object'`` by default. If ``template_object_name`` is ``'foo'``, this variable's name will be ``foo``. + diff --git a/docs/ref/index.txt b/docs/ref/index.txt index 3ffa1fcce1..6cc796d8e4 100644 --- a/docs/ref/index.txt +++ b/docs/ref/index.txt @@ -20,3 +20,4 @@ API Reference signals templates/index unicode + diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt index 2ec74e4306..177df12862 100644 --- a/docs/ref/models/fields.txt +++ b/docs/ref/models/fields.txt @@ -800,21 +800,22 @@ you can use the name of the model, rather than the model object itself:: class Manufacturer(models.Model): # ... -Note, however, that this only refers to models in the same ``models.py`` file -- -you cannot use a string to reference a model defined in another application or -imported from elsewhere. - -.. versionchanged:: 1.0 - Refering models in other applications must include the application label. +.. versionadded:: 1.0 -To refer to models defined in another -application, you must instead explicitly specify the application label. For -example, if the ``Manufacturer`` model above is defined in another application -called ``production``, you'd need to use:: +To refer to models defined in another application, you can explicitly specify +a model with the full application label. For example, if the ``Manufacturer`` +model above is defined in another application called ``production``, you'd +need to use:: class Car(models.Model): manufacturer = models.ForeignKey('production.Manufacturer') +This sort of reference can be useful when resolving circular import +dependencies between two applications. + +Database Representation +~~~~~~~~~~~~~~~~~~~~~~~ + Behind the scenes, Django appends ``"_id"`` to the field name to create its database column name. In the above example, the database table for the ``Car`` model will have a ``manufacturer_id`` column. (You can change this explicitly by @@ -824,6 +825,9 @@ deal with the field names of your model object. .. _foreign-key-arguments: +Arguments +~~~~~~~~~ + :class:`ForeignKey` accepts an extra set of arguments -- all optional -- that define the details of how the relation works. @@ -871,6 +875,9 @@ the model is related. This works exactly the same as it does for :class:`ForeignKey`, including all the options regarding :ref:`recursive ` and :ref:`lazy ` relationships. +Database Representation +~~~~~~~~~~~~~~~~~~~~~~~ + Behind the scenes, Django creates an intermediary join table to represent the many-to-many relationship. By default, this table name is generated using the names of the two tables being joined. Since some databases don't support table @@ -882,6 +889,9 @@ You can manually provide the name of the join table using the .. _manytomany-arguments: +Arguments +~~~~~~~~~ + :class:`ManyToManyField` accepts an extra set of arguments -- all optional -- that control how the relationship functions. diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt index 6c08fe079e..eb8fbfd833 100644 --- a/docs/ref/models/querysets.txt +++ b/docs/ref/models/querysets.txt @@ -616,6 +616,8 @@ call, since they are conflicting options. Both the ``depth`` argument and the ability to specify field names in the call to ``select_related()`` are new in Django version 1.0. +.. _extra: + ``extra(select=None, where=None, params=None, tables=None, order_by=None, select_params=None)`` ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- cgit v1.3