python/lib/django_1_4/docs/releases/1.3-beta-1.txt

   1 ================================
   2 Django 1.3 beta 1 release notes
   3 ================================
   4
   5 Welcome to Django 1.3 beta 1!
   6
   7 This is the second in a series of preview/development releases leading
   8 up to the eventual release of Django 1.3. This release is primarily
   9 targeted at developers who are interested in trying out new features
  10 and testing the Django codebase to help identify and resolve bugs
  11 prior to the final 1.3 release.
  12
  13 As such, this release is *not* intended for production use, and any such use
  14 is discouraged.
  15
  16 What's new in Django 1.3 beta 1
  17 ===============================
  18
  19 Further tweaks to the staticfiles app
  20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  21
  22 Django 1.3 ships with a new contrib app :mod:`django.contrib.staticfiles`
  23 to help developers handle the static media files (images, CSS, JavaScript,
  24 etc.) that are needed to render a complete web page.
  25
  26 The :mod:`~django.contrib.staticfiles` app ships with the ability to
  27 automatically serve static files during development (if the :setting:`DEBUG`
  28 setting is ``True``) when using the :djadmin:`runserver` management command.
  29 Based on feedback from the community this release adds two new options to the
  30 :djadmin:`runserver` command to modify this behavior:
  31
  32 * ``--nostatic``: prevents the :djadmin:`runserver` command from serving
  33   files completely.
  34
  35 * ``--insecure``: enables serving of static files even if running with
  36   :setting:`DEBUG` set to False. (This is **not** recommended!)
  37
  38 See the :doc:`staticfiles reference documentation </ref/contrib/staticfiles>`
  39 for more details, or learn :doc:`how to manage static files
  40 </howto/static-files>`.
  41
  42 Translation comments
  43 ~~~~~~~~~~~~~~~~~~~~
  44
  45 If you would like to give translators hints about a translatable string, you
  46 can add a comment prefixed with the ``Translators`` keyword on the line
  47 preceding the string, e.g.::
  48
  49     def my_view(request):
  50         # Translators: This message appears on the home page only
  51         output = ugettext("Welcome to my site.")
  52
  53 The comment will appear in the resulting .po file and should also be
  54 displayed by most translation tools.
  55
  56 For more information, see :ref:`translator-comments`.
  57
  58 Permissions for inactive users
  59 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  60
  61 If you provide a custom auth backend with ``supports_inactive_user`` set to
  62 ``True``, an inactive user model will check the backend for permissions.
  63 This is useful for further centralizing the permission handling. See the
  64 :doc:`authentication docs </topics/auth>` for more details.
  65
  66 Backwards-incompatible changes in 1.3 alpha 2
  67 =============================================
  68
  69 Change to admin lookup filters
  70 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  71
  72 The Django admin has long had an undocumented "feature" allowing savvy
  73 users to manipulate the query string of changelist pages to filter the
  74 list of objects displayed. However, this also creates a security
  75 issue, as a staff user with sufficient knowledge of model structure
  76 could use this "feature" to gain access to information he or she would
  77 not normally have.
  78
  79 As a result, changelist filtering now explicitly validates all lookup
  80 arguments in the query string, and permits only fields which are
  81 directly on the model, or relations explicitly permitted by the
  82 ``ModelAdmin`` definition. If you were relying on this undocumented
  83 feature, you will need to update your ``ModelAdmin`` definitions to
  84 whitelist the relations you choose to expose for filtering.
  85
  86 Introduction of STATIC_URL and STATIC_ROOT settings
  87 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  88
  89 The newly introduced :mod:`~django.contrib.staticfiles` app -- which extends
  90 Django's abilities to handle static files for apps and projects -- required the
  91 additon of two new settings to refer to those files in templates and code,
  92 especially in contrast to the :setting:`MEDIA_URL` and :setting:`MEDIA_ROOT`
  93 settings that refer to user-uploaded files.
  94
  95 Prior to 1.3 alpha 2 these settings were called ``STATICFILES_URL`` and
  96 ``STATICFILES_ROOT`` to follow the naming scheme for app-centric settings.
  97 Based on feedback from the community it became apparent that those settings
  98 created confusion, especially given the fact that handling static files is also
  99 desired outside the use of the optional :mod:`~django.contrib.staticfiles` app.
 100
 101 As a result, we took the following steps to rectify the issue:
 102
 103 * Two new global settings were added that will be used by, **but are not
 104   limited to**, the :doc:`staticfiles</ref/contrib/staticfiles>` app:
 105
 106 * :setting:`STATIC_ROOT` (formally ``STATICFILES_ROOT``)
 107
 108 * :setting:`STATIC_URL` (formally ``STATICFILES_URL``)
 109
 110 * The ``django.contrib.staticfiles.templatetags.staticfiles.get_staticfiles_prefix``
 111   template tag was moved to Django's core (``django.templatetags.static``) and
 112   renamed to :ttag:`get_static_prefix`.
 113
 114 * The ``django.contrib.staticfiles.context_processors.staticfiles``
 115   context processor was moved to Django's core
 116   (``django.core.context_processors.static``) and renamed to
 117   :func:`~django.core.context_processors.static`.
 118
 119 * :ref:`form-media-paths` now uses :setting:`STATIC_URL` as the prefix
 120   **if the value is not None**, and falls back to the previously used
 121   :setting:`MEDIA_URL` setting otherwise.
 122
 123 Changes to the login methods of the admin
 124 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 125
 126 In previous version the admin app defined login methods in multiple locations
 127 and ignored the almost identical implementation in the already used auth app.
 128 A side effect of this duplication was the missing adoption of the changes made
 129 in r12634_ to support a broader set of characters for usernames.
 130
 131 This release refactors the admin's login mechanism to use a subclass of the
 132 :class:`~django.contrib.auth.forms.AuthenticationForm` instead of a manual
 133 form validation. The previously undocumented method
 134 ``'django.contrib.admin.sites.AdminSite.display_login_form'`` has been removed
 135 in favor of a new :attr:`~django.contrib.admin.AdminSite.login_form`
 136 attribute.
 137
 138 .. _r12634: https://code.djangoproject.com/changeset/12634
 139
 140 Changes to ``USStateField``
 141 ===========================
 142
 143 The :mod:`django.contrib.localflavor` application contains collections
 144 of code relevant to specific countries or cultures. One such is
 145 :class:`~django.contrib.localflavor.us.models.USStateField`, which
 146 provides a field for storing the two-letter postal abbreviation of a
 147 U.S. state. This field has consistently caused problems, however,
 148 because it is often used to store the state portion of a U.S postal
 149 address, but not all "states" recognized by the U.S Postal Service are
 150 actually states of the U.S. or even U.S. territory. Several
 151 compromises over the list of choices resulted in some users feeling
 152 the field supported too many locations, while others felt it supported
 153 too few.
 154
 155 In Django 1.3 we're taking a new approach to this problem, implemented
 156 as a pair of changes:
 157
 158 * The choice list for `USStateField` has changed. Previously, it
 159   consisted of the 50 U.S. states, the District of Columbia and
 160   U.S. overseas territories. As of Django 1.3 it includes all previous
 161   choices, plus the U.S. Armed Forces postal codes.
 162
 163 * A new model field,
 164   :class:`django.contrib.localflavor.us.models.USPostalCodeField`, has
 165   been added which draws its choices from a list of all postal
 166   abbreviations recognized by the U.S Postal Service. This includes
 167   all abbreviations recognized by `USStateField`, plus three
 168   independent nations -- the Federated States of Micronesia, the
 169   Republic of the Marshall Islands and the Republic of Palau -- which
 170   are serviced under treaty by the U.S. postal system. A new form
 171   widget, :class:`django.contrib.localflavor.us.forms.USPSSelect`, is
 172   also available and provides the same set of choices.
 173
 174 Additionally, several finer-grained choice tuples are provided which
 175 allow mixing and matching of subsets of the U.S. states and
 176 territories, and other locations serviced by the U.S. postal
 177 system. Consult the :mod:`django.contrib.localflavor` documentation
 178 for more details.
 179
 180 The change to `USStateField` is technically backwards-incompatible for
 181 users who expect this field to exclude Armed Forces locations. If you
 182 need to support U.S. mailing addresses without Armed Forces locations,
 183 see the list of choice tuples available in the localflavor
 184 documentation.
 185
 186 The Django 1.3 roadmap
 187 ======================
 188
 189 Before the final Django 1.3 release, several other preview/development
 190 releases will be made available. The current schedule consists of at
 191 least the following:
 192
 193 * Week of **January 24, 2011**: First Django 1.3 release
 194   candidate. String freeze for translations.
 195
 196 * Week of **January 31, 2011**: Django 1.3 final release.
 197
 198 If necessary, additional beta or release-candidate packages
 199 will be issued prior to the final 1.3 release. Django 1.3 will be
 200 released approximately one week after the final release candidate.
 201
 202
 203 What you can do to help
 204 =======================
 205
 206 In order to provide a high-quality 1.3 release, we need your help. Although this
 207 beta release is, again, *not* intended for production use, you can help the
 208 Django team by trying out the beta codebase in a safe test environment and
 209 reporting any bugs or issues you encounter. The Django ticket tracker is the
 210 central place to search for open issues:
 211
 212 * https://code.djangoproject.com/timeline
 213
 214 Please open new tickets if no existing ticket corresponds to a problem you're
 215 running into.
 216
 217 Additionally, discussion of Django development, including progress toward the
 218 1.3 release, takes place daily on the django-developers mailing list:
 219
 220 * http://groups.google.com/group/django-developers
 221
 222 ... and in the ``#django-dev`` IRC channel on ``irc.freenode.net``. If you're
 223 interested in helping out with Django's development, feel free to join the
 224 discussions there.
 225
 226 Django's online documentation also includes pointers on how to contribute to
 227 Django:
 228
 229 * :doc:`How to contribute to Django </internals/contributing/index>`
 230
 231 Contributions on any level -- developing code, writing documentation or simply
 232 triaging tickets and helping to test proposed bugfixes -- are always welcome and
 233 appreciated.