newforms-admin: Merged from trunk up to [7435].

git-svn-id: http://code.djangoproject.com/svn/django/branches/newforms-admin@7436 bcc190cf-cafb-0310-a4f2-bffc1f526a37

docs/authentication.txt

@@ -819,16 +819,17 @@ Django developers are currently discussing.
 Default permissions
 -------------------
 
-Three basic permissions -- add, change and delete -- are automatically created
-for each Django model that has a ``class Admin`` set. Behind the scenes, these
-permissions are added to the ``auth_permission`` database table when you run
-``manage.py syncdb``.
+When ``django.contrib.auth`` is listed in your ``INSTALLED_APPS``
+setting, it will ensure that three default permissions -- add, change
+and delete -- are created for each Django model defined in one of your
+installed applications.
 
-Note that if your model doesn't have ``class Admin`` set when you run
-``syncdb``, the permissions won't be created. If you initialize your database
-and add ``class Admin`` to models after the fact, you'll need to run
-``manage.py syncdb`` again. It will create any missing permissions for
-all of your installed apps.
+These permissions will be created when you run ``manage.py syncdb``;
+the first time you run ``syncdb`` after adding ``django.contrib.auth``
+to ``INSTALLED_APPS``, the default permissions will be created for all
+previously-installed models, as well as for any new models being
+installed at that time. Afterward, it will create default permissions
+for new models each time you run ``manage.py syncdb``.
 
 Custom permissions
 ------------------

docs/modelforms.txt

@@ -121,6 +121,7 @@ A full example
 Consider this set of models::
 
     from django.db import models
+    from django.newforms import ModelForm
 
     TITLE_CHOICES = (
         ('MR', 'Mr.'),

docs/newforms.txt

@@ -1552,12 +1552,15 @@ additional required argument:
 ``ModelChoiceField``
 ~~~~~~~~~~~~~~~~~~~~
 
-Allows the selection of a single model object, suitable for representing a
-foreign key. The method receives an object as an argument and must return a
-string to represent it.
+Allows the selection of a single model object, suitable for
+representing a foreign key.
 
-The labels for the choice field call the ``__unicode__`` method of the model to
-generate string representations. To provide custom labels, subclass ``ModelChoiceField`` and override ``label_for_model``::
+The ``__unicode__`` method of the model will be called to generate
+string representations of the objects for use in the field's choices;
+to provide customized representations, subclass ``ModelChoiceField``
+and override ``label_from_instance``. This method will receive a model
+object, and should return a string suitable for representing it. For
+example::
 
     class MyModelChoiceField(ModelChoiceField):
         def label_from_instance(self, obj):
@@ -1566,9 +1569,10 @@ generate string representations. To provide custom labels, subclass ``ModelChoic
 ``ModelMultipleChoiceField``
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Allows the selection of one or more model objects, suitable for representing a
-many-to-many relation. As with ``ModelChoiceField``, you can use
-``label_from_instance`` to customize the object labels.
+Allows the selection of one or more model objects, suitable for
+representing a many-to-many relation. As with ``ModelChoiceField``,
+you can use ``label_from_instance`` to customize the object
+representations.
 
 Creating custom fields
 ----------------------

docs/tutorial04.txt

@@ -37,7 +37,7 @@ A quick rundown:
       form will alter data server-side. Whenever you create a form that alters
       data server-side, use ``method="post"``. This tip isn't specific to
       Django; it's just good Web development practice.
-    
+
     * ``forloop.counter`` indicates how many times the ``for`` tag has
       gone through its loop. For more information, see `the
       documentation for the "for" tag`_.
@@ -247,8 +247,8 @@ template. Note that we use ``dict()`` to return an altered dictionary in place.
     which is "lazy" and doesn't hit your database until it absolutely has to. By
     the time the database query happens, the ``object_detail`` generic view will
     have narrowed its scope down to a single object, so the eventual query will
-    only select one row from the database. 
-    
+    only select one row from the database.
+
     If you'd like to know more about how that works, The Django database API
     documentation `explains the lazy nature of QuerySet objects`_.
 
@@ -266,9 +266,8 @@ from ``polls/views.py``. We don't need them anymore -- they have been replaced
 by generic views.
 
 The ``vote()`` view is still required. However, it must be modified to match
-the new templates and context variables. Change the template call from
-``polls/detail.html`` to ``polls/poll_detail.html``, and pass ``object`` in the
-context instead of ``poll``.
+the new context variables. In the ``render_to_response()`` call, rename the
+``poll`` context variable to ``object``.
 
 The last thing to do is fix the URL handling to account for the use of generic
 views. In the vote view above, we used the ``reverse()`` function to avoid
@@ -276,7 +275,7 @@ hard-coding our URLs. Now that we've switched to a generic view, we'll need to
 change the ``reverse()`` call to point back to our new generic view. We can't
 simply use the view function anymore -- generic views can be (and are) used
 multiple times -- but we can use the name we've given::
-    
+
     return HttpResponseRedirect(reverse('poll_results', args=(p.id,)))
 
 Run the server, and use your new polling app based on generic views.