PageRenderTime 103ms CodeModel.GetById 60ms app.highlight 2ms RepoModel.GetById 38ms app.codeStats 0ms

/docs/releases/1.3-beta-1.txt

https://code.google.com/p/mango-py/
Plain Text | 233 lines | 175 code | 58 blank | 0 comment | 0 complexity | b20a88c5d84a1e3abc53ba6296aa0db8 MD5 | raw file
  1================================
  2Django 1.3 beta 1 release notes
  3================================
  4
  5Welcome to Django 1.3 beta 1!
  6
  7This is the second in a series of preview/development releases leading
  8up to the eventual release of Django 1.3. This release is primarily
  9targeted at developers who are interested in trying out new features
 10and testing the Django codebase to help identify and resolve bugs
 11prior to the final 1.3 release.
 12
 13As such, this release is *not* intended for production use, and any such use
 14is discouraged.
 15
 16What's new in Django 1.3 beta 1
 17===============================
 18
 19Further tweaks to the staticfiles app
 20~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 21
 22Django 1.3 ships with a new contrib app :mod:`django.contrib.staticfiles`
 23to help developers handle the static media files (images, CSS, JavaScript,
 24etc.) that are needed to render a complete web page.
 25
 26The :mod:`~django.contrib.staticfiles` app ships with the ability to
 27automatically serve static files during development (if the :setting:`DEBUG`
 28setting is ``True``) when using the :djadmin:`runserver` management command.
 29Based 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
 38See the :doc:`staticfiles reference documentation </ref/contrib/staticfiles>`
 39for more details, or learn :doc:`how to manage static files
 40</howto/static-files>`.
 41
 42Translation comments
 43~~~~~~~~~~~~~~~~~~~~
 44
 45If you would like to give translators hints about a translatable string, you
 46can add a comment prefixed with the ``Translators`` keyword on the line
 47preceding 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
 53The comment will appear in the resulting .po file and should also be
 54displayed by most translation tools.
 55
 56For more information, see :ref:`translator-comments`.
 57
 58Permissions for inactive users
 59~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 60
 61If you provide a custom auth backend with ``supports_inactive_user`` set to
 62``True``, an inactive user model will check the backend for permissions.
 63This is useful for further centralizing the permission handling. See the
 64:doc:`authentication docs </topics/auth>` for more details.
 65
 66Backwards-incompatible changes in 1.3 alpha 2
 67=============================================
 68
 69Change to admin lookup filters
 70~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 71
 72The Django admin has long had an undocumented "feature" allowing savvy
 73users to manipulate the query string of changelist pages to filter the
 74list of objects displayed. However, this also creates a security
 75issue, as a staff user with sufficient knowledge of model structure
 76could use this "feature" to gain access to information he or she would
 77not normally have.
 78
 79As a result, changelist filtering now explicitly validates all lookup
 80arguments in the query string, and permits only fields which are
 81directly on the model, or relations explicitly permitted by the
 82``ModelAdmin`` definition. If you were relying on this undocumented
 83feature, you will need to update your ``ModelAdmin`` definitions to
 84whitelist the relations you choose to expose for filtering.
 85
 86Introduction of STATIC_URL and STATIC_ROOT settings
 87~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 88
 89The newly introduced :mod:`~django.contrib.staticfiles` app -- which extends
 90Django's abilities to handle static files for apps and projects -- required the
 91additon of two new settings to refer to those files in templates and code,
 92especially in contrast to the :setting:`MEDIA_URL` and :setting:`MEDIA_ROOT`
 93settings that refer to user-uploaded files.
 94
 95Prior to 1.3 alpha 2 these settings were called ``STATICFILES_URL`` and
 96``STATICFILES_ROOT`` to follow the naming scheme for app-centric settings.
 97Based on feedback from the community it became apparent that those settings
 98created confusion, especially given the fact that handling static files is also
 99desired outside the use of the optional :mod:`~django.contrib.staticfiles` app.
100
101As 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
123Changes to the login methods of the admin
124~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
125
126In previous version the admin app defined login methods in multiple locations
127and ignored the almost identical implementation in the already used auth app.
128A side effect of this duplication was the missing adoption of the changes made
129in r12634_ to support a broader set of characters for usernames.
130
131This release refactors the admin's login mechanism to use a subclass of the
132:class:`~django.contrib.auth.forms.AuthenticationForm` instead of a manual
133form validation. The previously undocumented method
134``'django.contrib.admin.sites.AdminSite.display_login_form'`` has been removed
135in favor of a new :attr:`~django.contrib.admin.AdminSite.login_form`
136attribute.
137
138.. _r12634: http://code.djangoproject.com/changeset/12634
139
140Changes to ``USStateField``
141===========================
142
143The :mod:`django.contrib.localflavor` application contains collections
144of code relevant to specific countries or cultures. One such is
145:class:`~django.contrib.localflavor.us.models.USStateField`, which
146provides a field for storing the two-letter postal abbreviation of a
147U.S. state. This field has consistently caused problems, however,
148because it is often used to store the state portion of a U.S postal
149address, but not all "states" recognized by the U.S Postal Service are
150actually states of the U.S. or even U.S. territory. Several
151compromises over the list of choices resulted in some users feeling
152the field supported too many locations, while others felt it supported
153too few.
154
155In Django 1.3 we're taking a new approach to this problem, implemented
156as 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
174Additionally, several finer-grained choice tuples are provided which
175allow mixing and matching of subsets of the U.S. states and
176territories, and other locations serviced by the U.S. postal
177system. Consult the :mod:`django.contrib.localflavor` documentation
178for more details.
179
180The change to `USStateField` is technically backwards-incompatible for
181users who expect this field to exclude Armed Forces locations. If you
182need to support U.S. mailing addresses without Armed Forces locations,
183see the list of choice tuples available in the localflavor
184documentation.
185
186The Django 1.3 roadmap
187======================
188
189Before the final Django 1.3 release, several other preview/development
190releases will be made available. The current schedule consists of at
191least 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
198If necessary, additional beta or release-candidate packages
199will be issued prior to the final 1.3 release. Django 1.3 will be
200released approximately one week after the final release candidate.
201
202
203What you can do to help
204=======================
205
206In order to provide a high-quality 1.3 release, we need your help. Although this
207beta release is, again, *not* intended for production use, you can help the
208Django team by trying out the beta codebase in a safe test environment and
209reporting any bugs or issues you encounter. The Django ticket tracker is the
210central place to search for open issues:
211
212    * http://code.djangoproject.com/timeline
213
214Please open new tickets if no existing ticket corresponds to a problem you're
215running into.
216
217Additionally, discussion of Django development, including progress toward the
2181.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
223interested in helping out with Django's development, feel free to join the
224discussions there.
225
226Django's online documentation also includes pointers on how to contribute to
227Django:
228
229    * :doc:`How to contribute to Django </internals/contributing>`
230
231Contributions on any level -- developing code, writing documentation or simply
232triaging tickets and helping to test proposed bugfixes -- are always welcome and
233appreciated.