diff --git a/docs/ref/contrib/admin.txt b/docs/ref/contrib/admin.txt index da2f8a7e53..0c2b34509f 100644 --- a/docs/ref/contrib/admin.txt +++ b/docs/ref/contrib/admin.txt @@ -924,7 +924,9 @@ better to override only the section of the template which you need to change. To continue the example above, we want to add a new link next to the ``History`` tool for the ``Page`` model. After looking at ``change_form.html`` we determine that we only need to override the ``object-tools`` block. Therefore here is our -new ``change_form.html`` :: +new ``change_form.html`` : + +.. code-block:: html+django {% extends "admin/change_form.html" %} {% load i18n %} diff --git a/docs/ref/contrib/comments/index.txt b/docs/ref/contrib/comments/index.txt index 443c89d3c1..b6812a8e32 100644 --- a/docs/ref/contrib/comments/index.txt +++ b/docs/ref/contrib/comments/index.txt @@ -7,6 +7,8 @@ Django's comments framework .. module:: django.contrib.comments :synopsis: Django's comment framework +.. highlightlang:: html+django + Django includes a simple, yet customizable comments framework. The built-in comments framework can be used to attach comments to any model, so you can use it for comments on blog entries, photos, book chapters, or anything else. diff --git a/docs/ref/contrib/formtools/form-wizard.txt b/docs/ref/contrib/formtools/form-wizard.txt index 3923404f93..cf57e79884 100644 --- a/docs/ref/contrib/formtools/form-wizard.txt +++ b/docs/ref/contrib/formtools/form-wizard.txt @@ -169,8 +169,10 @@ You can specify it in two ways: * Pass :attr:`~django.contrib.formtools.wizard.FormWizard.extra_context` as extra parameters in the URLconf. -Here's a full example template:: - +Here's a full example template: + +.. code-block:: html+django + {% extends "base.html" %} {% block content %} diff --git a/docs/ref/django-admin.txt b/docs/ref/django-admin.txt index d53b0d8a55..9f25b1015e 100644 --- a/docs/ref/django-admin.txt +++ b/docs/ref/django-admin.txt @@ -385,7 +385,7 @@ makemessages ------------ .. versionchanged:: 1.0 - Before 1.0 this was the "bin/make-messages.py" command. + Before 1.0 this was the ``bin/make-messages.py`` command. Runs over the entire source tree of the current directory and pulls out all strings marked for translation. It creates (or updates) a message file in the diff --git a/docs/ref/files/file.txt b/docs/ref/files/file.txt index e864a7e004..1ea5865ea7 100644 --- a/docs/ref/files/file.txt +++ b/docs/ref/files/file.txt @@ -88,7 +88,7 @@ Additional ``ImageField`` attributes .. attribute:: File.height - Heigght of the image. + Height of the image. Additional methods on files attached to objects ----------------------------------------------- diff --git a/docs/ref/request-response.txt b/docs/ref/request-response.txt index 486ede0a78..89e5195a4e 100644 --- a/docs/ref/request-response.txt +++ b/docs/ref/request-response.txt @@ -93,18 +93,7 @@ All attributes except ``session`` should be considered read-only. A standard Python dictionary containing all cookies. Keys and values are strings. -.. attribute:: HttpRequest.FILES - - .. admonition:: Changed in Django development version - - In previous versions of Django, ``request.FILES`` contained - simple ``dict`` objects representing uploaded files. This is - no longer true -- files are represented by ``UploadedFile`` - objects as described below. - - These ``UploadedFile`` objects will emulate the old-style ``dict`` - interface, but this is deprecated and will be removed in the next - release of Django. +.. attribute:: HttpRequest.FILES A dictionary-like object containing all uploaded files. Each key in ``FILES`` is the ``name`` from the ````. Each @@ -123,6 +112,16 @@ All attributes except ``session`` should be considered read-only. ``enctype="multipart/form-data"``. Otherwise, ``FILES`` will be a blank dictionary-like object. + .. versionchanged:: 1.0 + + In previous versions of Django, ``request.FILES`` contained simple ``dict`` + objects representing uploaded files. This is no longer true -- files are + represented by ``UploadedFile`` objects as described below. + + These ``UploadedFile`` objects will emulate the old-style ``dict`` + interface, but this is deprecated and will be removed in the next release of + Django. + .. attribute:: HttpRequest.META A standard Python dictionary containing all available HTTP headers. diff --git a/docs/ref/templates/api.txt b/docs/ref/templates/api.txt index 80614ae35c..a220c79a96 100644 --- a/docs/ref/templates/api.txt +++ b/docs/ref/templates/api.txt @@ -29,7 +29,9 @@ content from a database or enable access to other template tags. Block tags are surrounded by ``"{%"`` and ``"%}"``. -Example template with block tags:: +Example template with block tags: + +.. code-block:: html+django {% if is_logged_in %}Thanks for logging in!{% else %}Please log in.{% endif %} @@ -37,7 +39,9 @@ A **variable** is a symbol within a template that outputs a value. Variable tags are surrounded by ``"{{"`` and ``"}}"``. -Example template with variables:: +Example template with variables: + +.. code-block:: html+django My first name is {{ first_name }}. My last name is {{ last_name }}. @@ -566,7 +570,7 @@ returns the resulting string:: The ``render_to_string`` shortcut takes one required argument -- ``template_name``, which should be the name of the template to load -and render -- and two optional arguments:: +and render -- and two optional arguments: dictionary A dictionary to be used as variables and values for the diff --git a/docs/ref/templates/builtins.txt b/docs/ref/templates/builtins.txt index 669b97d1e8..a28cf4f8c4 100644 --- a/docs/ref/templates/builtins.txt +++ b/docs/ref/templates/builtins.txt @@ -14,6 +14,8 @@ documentation for any custom tags or filters installed. Built-in tag reference ---------------------- +.. highlightlang:: html+django + .. templatetag:: autoescape autoescape @@ -473,7 +475,9 @@ Regroup a list of alike objects by a common attribute. This complex tag is best illustrated by use of an example: say that ``people`` is a list of people represented by dictionaries with ``first_name``, -``last_name``, and ``gender`` keys:: +``last_name``, and ``gender`` keys: + +.. code-block:: python people = [ {'first_name': 'George', 'last_name': 'Bush', 'gender': 'Male'}, @@ -530,7 +534,9 @@ the fact that the ``people`` list was ordered by ``gender`` in the first place. If the ``people`` list did *not* order its members by ``gender``, the regrouping would naively display more than one group for a single gender. For example, say the ``people`` list was set to this (note that the males are not grouped -together):: +together): + +.. code-block:: python people = [ {'first_name': 'Bill', 'last_name': 'Clinton', 'gender': 'Male'}, @@ -657,12 +663,16 @@ arguments in the URL. All arguments required by the URLconf should be present. For example, suppose you have a view, ``app_views.client``, whose URLconf takes a client ID (here, ``client()`` is a method inside the views file -``app_views.py``). The URLconf line might look like this:: +``app_views.py``). The URLconf line might look like this: + +.. code-block:: python ('^client/(\d+)/$', 'app_views.client') If this app's URLconf is included into the project's URLconf under a path -such as this:: +such as this: + +.. code-block:: python ('^clients/', include('project_name.app_name.urls')) @@ -682,19 +692,18 @@ Note that if the URL you're reversing doesn't exist, you'll get an :exc:`NoReverseMatch` exception raised, which will cause your site to display an error page. -**New in development verson:** If you'd like to retrieve a URL without displaying it, -you can use a slightly different call: +.. versionadded:: 1.0 + +If you'd like to retrieve a URL without displaying it, you can use a slightly +different call:: -.. code-block:: html+django {% url path.to.view arg, arg2 as the_url %} I'm linking to {{ the_url }} This ``{% url ... as var %}`` syntax will *not* cause an error if the view is -missing. In practice you'll use this to link to views that are optional: - -.. code-block:: html+django +missing. In practice you'll use this to link to views that are optional:: {% url path.to.view as the_url %} {% if the_url %} @@ -845,7 +854,9 @@ For example:: {{ value|dictsort:"name" }} -If ``value`` is:: +If ``value`` is: + +.. code-block:: python [ {'name': 'zed', 'age': 19}, @@ -853,7 +864,9 @@ If ``value`` is:: {'name': 'joe', 'age': 31}, ] -then the output would be:: +then the output would be: + +.. code-block:: python [ {'name': 'amy', 'age': 22}, @@ -1274,7 +1287,9 @@ Uses the same syntax as Python's list slicing. See http://diveintopython.org/native_data_types/lists.html#odbchelper.list.slice for an introduction. -Example: ``{{ some_list|slice:":2" }}`` +Example:: + + {{ some_list|slice:":2" }} .. templatefilter:: slugify diff --git a/docs/topics/forms/formsets.txt b/docs/topics/forms/formsets.txt index ca7aa2e14f..f3aa4a947e 100644 --- a/docs/topics/forms/formsets.txt +++ b/docs/topics/forms/formsets.txt @@ -306,7 +306,9 @@ management form inside the template. Lets look at a sample view:: formset = ArticleFormSet() return render_to_response('manage_articles.html', {'formset': formset}) -The ``manage_articles.html`` template might look like this:: +The ``manage_articles.html`` template might look like this: + +.. code-block:: html+django
However the above can be slightly shortcutted and let the formset itself deal -with the management form:: +with the management form: + +.. code-block:: html+django