diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/authentication.txt | 19 | ||||
| -rw-r--r-- | docs/modelforms.txt | 1 | ||||
| -rw-r--r-- | docs/newforms.txt | 20 | ||||
| -rw-r--r-- | docs/tutorial04.txt | 13 |
4 files changed, 29 insertions, 24 deletions
diff --git a/docs/authentication.txt b/docs/authentication.txt index c24d1ef62d..28e73faba7 100644 --- a/docs/authentication.txt +++ b/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 ------------------ diff --git a/docs/modelforms.txt b/docs/modelforms.txt index 554aeb7ea0..a76d797527 100644 --- a/docs/modelforms.txt +++ b/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.'), diff --git a/docs/newforms.txt b/docs/newforms.txt index 4f59400949..41930c0605 100644 --- a/docs/newforms.txt +++ b/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 ---------------------- diff --git a/docs/tutorial04.txt b/docs/tutorial04.txt index f09f08ce56..78f954d632 100644 --- a/docs/tutorial04.txt +++ b/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. |