Code

Changes between Version 1 and Version 2 of UpgradingNotes


Ignore:
Timestamp:
11/13/09 17:05:57 (4 years ago)
Author:
lukeplant
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • UpgradingNotes

    v1 v2  
    55Before upgrading to any version of Django, you should check all the notes for the version you are upgrading to '''and''' for any intermediate versions listed on this page.  Changes that are in trunk and not yet in any released version are listed at the top of this page. 
    66 
     7In addition to these changes, you should be aware of features that may have been removed, or will be removed soon, in the [http://docs.djangoproject.com/en/dev/internals/deprecation/ Deprecation timeline] 
     8 
    79For changes made before version 1.0, see BackwardsIncompatibleChanges. 
    810 
    911== Trunk == 
    1012 
    11 TODO 
     13=== CSRF Protection === 
     14 
     15There have been large changes to the way that CSRF protection works, detailed in 
     16[http://docs.djangoproject.com/en/dev/ref/contrib/csrf/ the CSRF documentaton], which has full upgrade notes. The following are the major changes that developers must be aware of: 
     17 
     18 * `CsrfResponseMiddleware` and `CsrfMiddleware` have been deprecated, and 
     19   will be removed completely in Django 1.4, in favour of a template tag that 
     20   should be inserted into forms. 
     21 
     22 * All contrib apps use a `csrf_protect` decorator to protect the view.  This 
     23   requires the use of the csrf_token template tag in the template, so if you 
     24   have used custom templates for contrib views, (which includes things like 
     25   a custom login template), you MUST READ THE UPGRADE INSTRUCTIONS to fix those templates. 
     26 
     27 * `CsrfViewMiddleware` is included in `MIDDLEWARE_CLASSES` by 
     28   default. This turns on CSRF protection by default, so that views that accept 
     29   POST requests need to be written to work with the middleware.  Instructions 
     30   on how to do this are found in the CSRF docs. 
     31 
     32 * All of the CSRF code has moved from contrib to core (with backwards compatible 
     33   imports in the old locations, which are deprecated). 
     34 
     35=== !LazyObject === 
     36 
     37`LazyObject` is an undocumented utility class used for lazily wrapping other 
     38objects of unknown type.  In Django 1.1 and earlier, it handled introspection in 
     39a non-standard way, depending on wrapped objects implementing a public method 
     40`get_all_members()`. Since this could easily lead to name clashes, it has been 
     41changed to use the standard method, involving `__members__` and `__dir__()`. 
     42If you used `LazyObject` in your own code, and implemented the 
     43`get_all_members()` method for wrapped objects, you need to make the following 
     44changes: 
     45 
     46 * If your class does not have special requirements for introspection (i.e. you 
     47   have not implemented `__getattr__()` or other methods that allow for 
     48   attributes not discoverable by normal mechanisms), you can simply remove the 
     49   `get_all_members()` method.  The default implementation on `LazyObject` 
     50   will do the right thing. 
     51 
     52 * If you have more complex requirements for introspection, first rename the 
     53   `get_all_members` method to `__dir__`.  This is the standard method, 
     54   from Python 2.6 onwards, for supporting introspection.  If you require 
     55   support for Python < 2.6, add the following code to the class: 
     56{{{ 
     57#!python 
     58    __members__ = property(lambda self: self.__dir__()) 
     59}}} 
     60 
    1261 
    1362== Django 1.1 ==