mirror of
https://github.com/django/django.git
synced 2024-12-24 10:05:46 +00:00
24acca4139
git-svn-id: http://code.djangoproject.com/svn/django/trunk@13981 bcc190cf-cafb-0310-a4f2-bffc1f526a37
122 lines
4.8 KiB
Plaintext
122 lines
4.8 KiB
Plaintext
============================================
|
|
Django 1.3 release notes - UNDER DEVELOPMENT
|
|
============================================
|
|
|
|
This page documents release notes for the as-yet-unreleased Django
|
|
1.3. As such, it's tentative and subject to change. It provides
|
|
up-to-date information for those who are following trunk.
|
|
|
|
Django 1.3 includes a number of nifty `new features`_, lots of bug
|
|
fixes and an easy upgrade path from Django 1.2.
|
|
|
|
.. _new features: `What's new in Django 1.3`_
|
|
|
|
.. _backwards-incompatible-changes-1.3:
|
|
|
|
Backwards-incompatible changes in 1.3
|
|
=====================================
|
|
|
|
PasswordInput default rendering behavior
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Prior to Django 1.3, a :class:`~django.forms.PasswordInput` would render
|
|
data values like any other form. If a form submission raised an error,
|
|
the password that was submitted would be reflected to the client as form
|
|
data populating the form for resubmission.
|
|
|
|
This had the potential to leak passwords, as any failed password
|
|
attempt would cause the password that was typed to be sent back to the
|
|
client.
|
|
|
|
In Django 1.3, the default behavior of
|
|
:class:`~django.forms.PasswordInput` is to suppress the display of
|
|
password values. This change doesn't alter the way form data is
|
|
validated or handled. It only affects the user experience with
|
|
passwords on a form when they make an error submitting form data (such
|
|
as on unsuccessful logins, or when completing a registration form).
|
|
|
|
If you want restore the pre-Django 1.3 behavior, you need to pass in a
|
|
custom widget to your form that sets the ``render_value`` argument::
|
|
|
|
class LoginForm(forms.Form):
|
|
username = forms.CharField(max_length=100)
|
|
password = forms.PasswordField(widget=forms.PasswordInput(render_value=True))
|
|
|
|
Clearable default widget for FileField
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Django 1.3 now includes a ``ClearableFileInput`` form widget in addition to
|
|
``FileInput``. ``ClearableFileInput`` renders with a checkbox to clear the
|
|
field's value (if the field has a value and is not required); ``FileInput``
|
|
provided no means for clearing an existing file from a ``FileField``.
|
|
|
|
``ClearableFileInput`` is now the default widget for a ``FileField``, so
|
|
existing forms including ``FileField`` without assigning a custom widget will
|
|
need to account for the possible extra checkbox in the rendered form output.
|
|
|
|
To return to the previous rendering (without the ability to clear the
|
|
``FileField``), use the ``FileInput`` widget in place of
|
|
``ClearableFileInput``. For instance, in a ``ModelForm`` for a hypothetical
|
|
``Document`` model with a ``FileField`` named ``document``::
|
|
|
|
from django import forms
|
|
from myapp.models import Document
|
|
|
|
class DocumentForm(forms.ModelForm):
|
|
class Meta:
|
|
model = Document
|
|
widgets = {'document': forms.FileInput}
|
|
|
|
.. _deprecated-features-1.3:
|
|
|
|
Features deprecated in 1.3
|
|
==========================
|
|
|
|
Django 1.3 deprecates some features from earlier releases.
|
|
These features are still supported, but will be gradually phased out
|
|
over the next few release cycles.
|
|
|
|
Code taking advantage of any of the features below will raise a
|
|
``PendingDeprecationWarning`` in Django 1.3. This warning will be
|
|
silent by default, but may be turned on using Python's `warnings
|
|
module`_, or by running Python with a ``-Wd`` or `-Wall` flag.
|
|
|
|
.. _warnings module: http://docs.python.org/library/warnings.html
|
|
|
|
In Django 1.4, these warnings will become a ``DeprecationWarning``,
|
|
which is *not* silent. In Django 1.5 support for these features will
|
|
be removed entirely.
|
|
|
|
.. seealso::
|
|
|
|
For more details, see the documentation :doc:`Django's release process
|
|
</internals/release-process>` and our :doc:`deprecation timeline
|
|
</internals/deprecation>`.`
|
|
|
|
``mod_python`` support
|
|
~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The ``mod_python`` library has not had a release since 2007 or a commit since
|
|
2008. The Apache Foundation board voted to remove ``mod_python`` from the set
|
|
of active projects in its version control repositories, and its lead developer
|
|
has shifted all of his efforts toward the lighter, slimmer, more stable, and
|
|
more flexible ``mod_wsgi`` backend.
|
|
|
|
If you are currently using the ``mod_python`` request handler, it is strongly
|
|
encouraged you redeploy your Django instances using :doc:`mod_wsgi
|
|
</howto/deployment/modwsgi>`.
|
|
|
|
What's new in Django 1.3
|
|
========================
|
|
|
|
Logging
|
|
~~~~~~~
|
|
|
|
Django 1.3 adds framework-level support for Python's logging module.
|
|
This means you can now esaily configure and control logging as part of
|
|
your Django project. A number of logging handlers and logging calls
|
|
have been added to Django's own code as well -- most notably, the
|
|
error emails sent on a HTTP 500 server error are now handled as a
|
|
logging activity. See :doc:`the documentation on Django's logging
|
|
interface </topics/logging>` for more details.
|