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