Changes between Version 1 and Version 2 of UpgradingNotes

11/13/09 19:05:57 (7 years ago)
Luke Plant



  • 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.
     7In addition to these changes, you should be aware of features that may have been removed, or will be removed soon, in the [ Deprecation timeline]
    79For changes made before version 1.0, see BackwardsIncompatibleChanges.
    911== Trunk ==
    11 TODO
     13=== CSRF Protection ===
     15There have been large changes to the way that CSRF protection works, detailed in
     16[ the CSRF documentaton], which has full upgrade notes. The following are the major changes that developers must be aware of:
     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.
     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.
     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.
     32 * All of the CSRF code has moved from contrib to core (with backwards compatible
     33   imports in the old locations, which are deprecated).
     35=== !LazyObject ===
     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
     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.
     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:
     58    __members__ = property(lambda self: self.__dir__())
    1362== Django 1.1 ==
Back to Top