queryset-refactor: Merged to [6220]

git-svn-id: http://code.djangoproject.com/svn/django/branches/queryset-refactor@6337 bcc190cf-cafb-0310-a4f2-bffc1f526a37

5 files changed, 121 insertions, 8 deletions

diff --git a/docs/authentication.txt b/docs/authentication.txt
index 131a8930b5..820aff2712 100644
--- a/docs/authentication.txt
+++ b/docs/authentication.txt
@@ -402,11 +402,29 @@ introduced in Python 2.4::
     def my_view(request):
         # ...
 
+In the Django development version, ``login_required`` also takes an optional
+``redirect_field_name`` parameter. Example::
+    
+    from django.contrib.auth.decorators import login_required
+
+    def my_view(request):
+        # ...
+    my_view = login_required(redirect_field_name='redirect_to')(my_view)
+
+Again, an equivalent example of the more compact decorator syntax introduced in Python 2.4::
+    
+    from django.contrib.auth.decorators import login_required
+
+    @login_required(redirect_field_name='redirect_to')
+    def my_view(request):
+        # ...
+
 ``login_required`` does the following:
 
     * If the user isn't logged in, redirect to ``settings.LOGIN_URL``
       (``/accounts/login/`` by default), passing the current absolute URL
-      in the query string as ``next``. For example:
+      in the query string as ``next`` or the value of ``redirect_field_name``. 
+      For example:
       ``/accounts/login/?next=/polls/3/``.
     * If the user is logged in, execute the view normally. The view code is
       free to assume the user is logged in.
diff --git a/docs/databrowse.txt b/docs/databrowse.txt
index 81e9e8e83b..72e1c71720 100644
--- a/docs/databrowse.txt
+++ b/docs/databrowse.txt
@@ -58,4 +58,29 @@ How to use Databrowse
 
     4. Run the Django server and visit ``/databrowse/`` in your browser.
 
+Requiring user login
+====================
+
+You can restrict access to logged-in users with only a few extra lines of
+code. Simply add the following import to your URLconf::
+
+    from django.contrib.auth.decorators import login_required
+
+Then modify the URLconf so that the ``databrowse.site.root`` view is decorated
+with ``login_required``::
+
+    (r'^databrowse/(.*)', login_required(databrowse.site.root)),
+
+If you haven't already added support for user logins to your URLconf, as
+described in the `user authentication docs`_, then you will need to do so
+now with the following mapping::
+
+    (r'^accounts/login/$', 'django.contrib.auth.views.login'),
+
+The final step is to create the login form required by
+``django.contrib.auth.views.login``. The `user authentication docs`_
+provide full details and a sample template that can be used for this
+purpose.
+
 .. _template loader docs: ../templates_python/#loader-types
+.. _user authentication docs: ../authentication/
diff --git a/docs/django-admin.txt b/docs/django-admin.txt
index cdd31a2c48..68fcad24fe 100644
--- a/docs/django-admin.txt
+++ b/docs/django-admin.txt
@@ -627,14 +627,34 @@ This is useful in a number of ways:
       in any way, knowing that whatever data changes you're making are only
       being made to a test database.
 
-Note that this server can only run on the default port on localhost; it does
-not yet accept a ``host`` or ``port`` parameter.
-
-Also note that it does *not* automatically detect changes to your Python source
-code (as ``runserver`` does). It does, however, detect changes to templates.
+Note that this server does *not* automatically detect changes to your Python
+source code (as ``runserver`` does). It does, however, detect changes to
+templates.
 
 .. _unit tests: ../testing/
 
+--addrport [port number or ipaddr:port]
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Use ``--addrport`` to specify a different port, or IP address and port, from
+the default of 127.0.0.1:8000. This value follows exactly the same format and
+serves exactly the same function as the argument to the ``runserver`` subcommand.
+
+Examples:
+
+To run the test server on port 7000 with ``fixture1`` and ``fixture2``::
+
+    django-admin.py testserver --addrport 7000 fixture1 fixture2
+    django-admin.py testserver fixture1 fixture2 --addrport 8080
+
+(The above statements are equivalent. We include both of them to demonstrate
+that it doesn't matter whether the options come before or after the
+``testserver`` command.)
+
+To run on 1.2.3.4:7000 with a `test` fixture::
+
+    django-admin.py testserver --addrport 1.2.3.4:7000 test
+
 --verbosity
 ~~~~~~~~~~~
 
diff --git a/docs/model-api.txt b/docs/model-api.txt
index 27207aab6f..a8af05f676 100644
--- a/docs/model-api.txt
+++ b/docs/model-api.txt
@@ -221,8 +221,10 @@ The admin represents this as an ``<input type="text">`` (a single-line input).
 ~~~~~~~~~~~~~~
 
 A ``CharField`` that checks that the value is a valid e-mail address.
-This doesn't accept ``max_length``; its ``max_length`` is automatically set to
-75.
+
+In Django 0.96, this doesn't accept ``max_length``; its ``max_length`` is
+automatically set to 75. In the Django development version, ``max_length`` is
+set to 75 by default, but you can specify it to override default behavior.
 
 ``FileField``
 ~~~~~~~~~~~~~
@@ -1224,6 +1226,13 @@ together. It's used in the Django admin and is enforced at the database
 level (i.e., the appropriate ``UNIQUE`` statements are included in the
 ``CREATE TABLE`` statement).
 
+**New in Django development version**
+
+For convenience, unique_together can be a single list when dealing
+with a single set of fields::
+
+	unique_together = ("driver", "restaurant")
+
 ``verbose_name``
 ----------------
 
diff --git a/docs/shortcuts.txt b/docs/shortcuts.txt
new file mode 100644
index 0000000000..2c0dbb5663
--- /dev/null
+++ b/docs/shortcuts.txt
@@ -0,0 +1,41 @@
+=========================
+Django shortcut functions
+=========================
+
+The package ``django.shortcuts`` collects helper functions and classes that
+"span" multiple levels of MVC. In other words, these functions/classes
+introduce controlled coupling for convenience's sake.
+
+``render_to_response``
+======================
+
+``django.shortcuts.render_to_response`` renders a given template with a given
+context dictionary and returns an ``HttpResponse`` object with that rendered
+text.
+
+Example::
+
+    from django.shortcuts import render_to_response
+    r = render_to_response('myapp/template.html', {'foo': 'bar'})
+
+This example is equivalent to::
+
+    from django.http import HttpResponse
+    from django.template import Context, loader
+    t = loader.get_template('myapp/template.html')
+    c = Context({'foo': 'bar'})
+    r = HttpResponse(t.render(c))
+
+``get_object_or_404``
+=====================
+
+``django.shortcuts.get_object_or_404`` calls ``get()`` on a given model
+manager, but it raises ``django.http.Http404`` instead of the model's
+``DoesNotExist`` exception.
+
+``get_list_or_404``
+===================
+
+``django.shortcuts.get_list_or_404`` returns the result of ``filter()`` on a
+given model manager, raising ``django.http.Http404`` if the resulting list is
+empty.