Code

Changes between Version 265 and Version 266 of BackwardsIncompatibleChanges


Ignore:
Timestamp:
09/24/08 16:48:57 (6 years ago)
Author:
kmtracey
Comment:

Fixed a few more links into the old docs that were no longer going where they were intended to go

Legend:

Unmodified
Added
Removed
Modified
  • BackwardsIncompatibleChanges

    v265 v266  
    9696}}} 
    9797should be modified to read: 
     98 
     99 
    98100 
    99101 
     
    369371== Auto-escaping in templates == 
    370372 
    371 In [6671] a long-awaited feature was committed to make default HTML template usage a bit safe from some forms of cross-site scripting attacks. For full details, read the [http://www.djangoproject.com/documentation/templates/#automatic-html-escaping template author documentation] and the [http://www.djangoproject.com/documentation/templates_python/#filters-and-auto-escaping template filter documentation]. 
     373In [6671] a long-awaited feature was committed to make default HTML template usage a bit safe from some forms of cross-site scripting attacks. For full details, read the [http://docs.djangoproject.com/en/dev/topics/templates/#automatic-html-escaping template author documentation] and the [http://docs.djangoproject.com/en/dev/howto/custom-template-tags/#filters-and-auto-escaping template filter documentation]. 
    372374 
    373375Automatic HTML escaping (henceforth ''auto-escaping'') affects any variables in templates. It is only applied to variables and not to template tags. 
     
    409411      }}} 
    410412       
    411       The second and probably more robust way is to use {{{mark_safe()}}} where appropriate (see [http://www.djangoproject.com/documentation/templates_python/#filters-and-auto-escaping the documentation] for details) and go through each of your custom filters attaching {{{is_safe}}} and {{{needs_autoescape}}} attributes where necessary (again, the details are in the above documentation). 
     413      The second and probably more robust way is to use {{{mark_safe()}}} where appropriate (see [http://docs.djangoproject.com/en/dev/howto/custom-template-tags/#filters-and-auto-escaping the documentation] for details) and go through each of your custom filters attaching {{{is_safe}}} and {{{needs_autoescape}}} attributes where necessary (again, the details are in the above documentation). 
    412414       
    413       Have a look at Django's default filters (in {{{django/template/defaultfilters.py}}}) for examples of how mixed filters (those which behave differently depending upon whether auto-escaping is in effect or not) can be written. 
     415      Have a look at Django's default filters (in {{{django/template/defaultfilters.py}}}) for examples of how mixed filters (those which behave differently depending upon whether auto-escaping is in effect o/r not) can be written. 
    414416 
    415417The attributes on filter functions and the new {{{escape}}} behaviour mean that you can write templates and filters that will operate correctly in both auto-escaping and non-auto-escaping environments, so you're not forcing your decision onto users of your filters, if you distribute the code. 
     
    501503== Raise errors if extends is not the first tag of a template == 
    502504 
    503 In [7082] we removed the possibility of putting extends below other tags (in [7089]).   You may still put it below comment tags or whitespace.  Otherwise it will raise a !TemplateSyntaxError. This is not technically a backward incompatible change because documentation has always specified that [http://www.djangoproject.com/documentation/templates/#template-inheritance extends tags should be placed first in your templates], but it may break your code if you haven't followed those instructions. 
     505In [7082] we removed the possibility of putting extends below other tags (in [7089]).   You may still put it below comment tags or whitespace.  Otherwise it will raise a !TemplateSyntaxError. This is not technically a backward incompatible change because documentation has always specified that [http://docs.djangoproject.com/en/dev/topics/templates/#template-inheritance extends tags should be placed first in your templates], but it may break your code if you haven't followed those instructions. 
    504506 
    505507== Change es_AR to es-ar in LANGUAGES == 
     
    564566[7814] introduced changes to the way Django handles uploaded files. Most of the changes are in the form of added flexibility and performance (for details, see the [http://www.djangoproject.com/documentation/upload_handing/ upload handling documentation]). 
    565567 
    566 However, as part of the change, the representation of uploaded files has changed. Previous, uploaded files -- that is, entries in {{{request.FILES}}} -- were represented by simple dictionaries with a few well-known keys. Uploaded files are now represented by an [http://www.djangoproject.com/documentation/upload_handling/#uploaded-file-objects UploadedFile object], and thus the file's information is accessible through object attributes. Thus, given {{{f = request.FILES['some_field_name']}}}: 
     568However, as part of the change, the representation of uploaded files has changed. Previous, uploaded files -- that is, entries in {{{request.FILES}}} -- were represented by simple dictionaries with a few well-known keys. Uploaded files are now represented by an [http://docs.djangoproject.com/en/dev/topics/http/file-uploads/#uploadedfile-objects UploadedFile object], and thus the file's information is accessible through object attributes. Thus, given {{{f = request.FILES['some_field_name']}}}: 
    567569 
    568570|| '''Deprecated'''         || '''Replacement'''    || 
     
    832834}}} 
    833835 
    834 Before you would define an {{{edit_inline}}} database field option and give it the value of the type of inline you wanted, either {{{models.TABULAR}}} or {{{models.STACKED}}}. This is now done with classes and gives you much more flexibility over the options of a specific inline. See [http://www.djangoproject.com/documentation/admin/#inlinemodeladmin-objects the inlines documentation] to learn more. 
     836Before you would define an {{{edit_inline}}} database field option and give it the value of the type of inline you wanted, either {{{models.TABULAR}}} or {{{models.STACKED}}}. This is now done with classes and gives you much more flexibility over the options of a specific inline. See [http://docs.djangoproject.com/en/dev/ref/contrib/admin/#inlinemodeladmin-objects the inlines documentation] to learn more. 
    835837 
    836838=== Refactored inner Admin ```js``` option to media definitions === 
     
    883885    class Media: 
    884886        js = ( 
     887 
    885888            settings.ADMIN_MEDIA_PREFIX + "some_file.js", 
    886889        ) 
     
    11691172For MySQL users only: Due to a number of unintended side-effects and after carefully considering the alternatives, the changes from [7798] were reverted in [8319]. Thus, `__exact` filters in MySQL now use the database table's native collation setting to determine whether the match is case-sensitive or case-insensitive. 
    11701173 
    1171 [http://www.djangoproject.com/documentation/db-api/#exact The documentation] for `exact` has been updated to indicate how to control this behaviour. 
     1174[http://docs.djangoproject.com/en/dev/ref/models/querysets/#exact The documentation] for `exact` has been updated to indicate how to control this behaviour. 
    11721175 
    11731176== Added parameter to session backend save() method ==