diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/authentication.txt | 16 | ||||
| -rw-r--r-- | docs/django-admin.txt | 6 | ||||
| -rw-r--r-- | docs/fastcgi.txt | 4 | ||||
| -rw-r--r-- | docs/forms.txt | 10 | ||||
| -rw-r--r-- | docs/testing.txt | 22 |
5 files changed, 33 insertions, 25 deletions
diff --git a/docs/authentication.txt b/docs/authentication.txt index d10dda28ef..f161e9d357 100644 --- a/docs/authentication.txt +++ b/docs/authentication.txt @@ -82,14 +82,14 @@ Methods ``user_permissions``. ``User`` objects can access their related objects in the same way as any other `Django model`_:: - myuser.objects.groups = [group_list] - myuser.objects.groups.add(group, group,...) - myuser.objects.groups.remove(group, group,...) - myuser.objects.groups.clear() - myuser.objects.permissions = [permission_list] - myuser.objects.permissions.add(permission, permission, ...) - myuser.objects.permissions.remove(permission, permission, ...] - myuser.objects.permissions.clear() + myuser.groups = [group_list] + myuser.groups.add(group, group,...) + myuser.groups.remove(group, group,...) + myuser.groups.clear() + myuser.permissions = [permission_list] + myuser.permissions.add(permission, permission, ...) + myuser.permissions.remove(permission, permission, ...] + myuser.permissions.clear() In addition to those automatic API methods, ``User`` objects have the following custom methods: diff --git a/docs/django-admin.txt b/docs/django-admin.txt index 672200c5e7..ffafc83972 100644 --- a/docs/django-admin.txt +++ b/docs/django-admin.txt @@ -295,6 +295,8 @@ give you the option of creating a superuser immediately. test ---- +**New in Django development version** + Discover and run tests for all installed models. See `Testing Django applications`_ for more information. .. _testing django applications: ../testing/ @@ -348,6 +350,8 @@ options. --noinput --------- +**New in Django development version** + Inform django-admin that the user should NOT be prompted for any input. Useful if the django-admin script will be executed as an unattended, automated script. @@ -369,6 +373,8 @@ Example output:: --verbosity ----------- +**New in Django development version** + Example usage:: django-admin.py syncdb --verbosity=2 diff --git a/docs/fastcgi.txt b/docs/fastcgi.txt index 41d50d97a1..e2f4e933b4 100644 --- a/docs/fastcgi.txt +++ b/docs/fastcgi.txt @@ -270,7 +270,7 @@ In your Web root directory, add this to a file named ``.htaccess`` :: AddHandler fastcgi-script .fcgi RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-f - RewriteRule ^/(.*)$ /mysite.fcgi/$1 [QSA,L] + RewriteRule ^(.*)$ mysite.fcgi/$1 [QSA,L] Then, create a small script that tells Apache how to spawn your FastCGI program. Create a file ``mysite.fcgi`` and place it in your Web directory, and @@ -289,7 +289,7 @@ be sure to make it executable :: os.environ['DJANGO_SETTINGS_MODULE'] = "myproject.settings" from django.core.servers.fastcgi import runfastcgi - runfastcgi(["method=threaded", "daemonize=false"]) + runfastcgi(method="threaded", daemonize="false") Restarting the spawned server ----------------------------- diff --git a/docs/forms.txt b/docs/forms.txt index 67408f3c5d..d6ef6f791b 100644 --- a/docs/forms.txt +++ b/docs/forms.txt @@ -321,7 +321,7 @@ about editing an existing one? It's shockingly similar to creating a new one:: else: errors = {} # This makes sure the form accurate represents the fields of the place. - new_data = place.__dict__ + new_data = manipulator.flatten_data() form = forms.FormWrapper(manipulator, new_data, errors) return render_to_response('places/edit_form.html', {'form': form, 'place': place}) @@ -336,10 +336,10 @@ The only real differences are: * ``ChangeManipulator.original_object`` stores the instance of the object being edited. - * We set ``new_data`` to the original object's ``__dict__``. This makes - sure the form fields contain the current values of the object. - ``FormWrapper`` does not modify ``new_data`` in any way, and templates - cannot, so this is perfectly safe. + * We set ``new_data`` based upon ``flatten_data()`` from the manipulator. + ``flatten_data()`` takes the data from the original object under + manipulation, and converts it into a data dictionary that can be used + to populate form elements with the existing values for the object. * The above example uses a different template, so create and edit can be "skinned" differently if needed, but the form chunk itself is completely diff --git a/docs/testing.txt b/docs/testing.txt index f8158a0001..b1ede3e4cc 100644 --- a/docs/testing.txt +++ b/docs/testing.txt @@ -92,7 +92,8 @@ Writing unittests Like doctests, Django's unit tests use a standard library module: unittest_. As with doctests, Django's test runner looks for any unit test cases defined -in ``models.py``, or in a ``tests.py`` file in your application directory. +in ``models.py``, or in a ``tests.py`` file stored in the application +directory. An equivalent unittest test case for the above example would look like:: @@ -110,8 +111,9 @@ An equivalent unittest test case for the above example would look like:: self.assertEquals(self.cat.speak(), 'The cat says "meow"') When you `run your tests`_, the test utility will find all the test cases -(that is, subclasses of ``unittest.TestCase``) in ``tests.py``, automatically -build a test suite out of those test cases, and run that suite. +(that is, subclasses of ``unittest.TestCase``) in ``models.py`` and +``tests.py``, automatically build a test suite out of those test cases, +and run that suite. For more details about ``unittest``, see the `standard library unittest documentation`_. @@ -197,10 +199,10 @@ used as test conditions. .. _Selenium: http://www.openqa.org/selenium/ The Test Client is stateful; if a cookie is returned as part of a response, -that cookie is provided as part of the next request. Expiry policies for these -cookies are not followed; if you want a cookie to expire, either delete it -manually from ``client.cookies``, or create a new Client instance (which will -effectively delete all cookies). +that cookie is provided as part of the next request issued to that Client +instance. Expiry policies for these cookies are not followed; if you want +a cookie to expire, either delete it manually from ``client.cookies``, or +create a new Client instance (which will effectively delete all cookies). Making requests ~~~~~~~~~~~~~~~ @@ -210,7 +212,6 @@ no arguments at time of construction. Once constructed, the following methods can be invoked on the ``Client`` instance. ``get(path, data={})`` - Make a GET request on the provided ``path``. The key-value pairs in the data dictionary will be used to create a GET data payload. For example:: @@ -222,7 +223,6 @@ can be invoked on the ``Client`` instance. http://yoursite.com/customers/details/?name='fred'&age=7 ``post(path, data={})`` - Make a POST request on the provided ``path``. The key-value pairs in the data dictionary will be used to create the POST data payload. This payload will be transmitted with the mimetype ``multipart/form-data``. @@ -243,7 +243,6 @@ can be invoked on the ``Client`` instance. need to manually close the file after it has been provided to the POST. ``login(path, username, password)`` - In a production site, it is likely that some views will be protected with the @login_required URL provided by ``django.contrib.auth``. Interacting with a URL that has been login protected is a slightly complex operation, @@ -307,9 +306,12 @@ The following is a simple unit test using the Test Client:: # Every test needs a client self.client = Client() def test_details(self): + # Issue a GET request response = self.client.get('/customer/details/') + # Check that the respose is 200 OK self.failUnlessEqual(response.status_code, 200) + # Check that the rendered context contains 5 customers self.failUnlessEqual(len(response.context['customers']), 5) Fixtures |