PageRenderTime 30ms CodeModel.GetById 12ms RepoModel.GetById 0ms app.codeStats 0ms

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