23 Maret 2011
Selamat datang di Django 1.3!
Hampir setahun dalam membuat, The same applies1.3 termasuk sedikit new features dan cukup dari perbaikan kesalahan dan peningkatan pada fitur-fitur yang ada. Catatan terbitan ini melingkupi fitur-fitur baru di 1.2, dan juga beberapa backwards-incompatible changes anda ingin disadari dari ketika meningkatkan dari Django 1.2 atau versi terlama.
Fokus Django 1.3 kebanyakan pada memecahkan lebih kecil, permintaan fitur yang lama berdiri, tetapi tidak mencegah sedikit fitur baru cukup dignifikan dari mendarat, termasuk:
Sedapat mungkin, tentu saja, fitur-fitur baru diperkenalkan di sikap kesesuaian-kebelakang per kebijakan our API stability policy. Sebagai hasil dari kebijakan ini, Django 1.3 begins the deprecation process for some features.
Terbitan dari The same applies1.2 adalah penting untuk mempunyai pergantian pertama di kebijakan kesesuaian Python Django; sebelum Django 1.2, Django mendukung tiap versi 2.x dari Python mulai 2.3 keatas. Mulai Django 1.2, persyaratan minimal telah dimunculkan pada Python 2.4.
Django 1.3 lanjut mendukung Python 2.4, tetapi akan menjadi rangkaian terbitan Django akhir untuk melakukannya; dimuai dengan Django 1.4, versi Python minimal yang didukung akan menjadi 2.5. Sebuah dokumen menguraikan linimasa penuh kami untuk pengusangan Python 2.x dan berpindah ke Python 3.x akan diterbitkan secepatnya setelah terbitan Django 1.3.
Django 1.3 menambahkan sebuah keangka kerja yang mengizinkan anda menggunakan kelas sebagai tampilan. Ini berarti anda dapat menyusun tampilan dari kumpulan dari metode yang dapat di subkelaskan dan ditimpa untuk menyesiakan tampilan umum data tanpa harus menulis kode terlalu banyak.
Analog untuk semua tampilan umum berdasarkan-fungsi lama telah disediakam, bersama dengan kelas dasar tampilan umum lengkap yang dapat digunakan sebagai dasar untuk penggunaan kembali aplikasi yang dapat dengan mudah diperpanjang.
Lihat the documentation on class-based generic views untuk lebih rinci. Ada juga sebuah dokumen untuk membantu anda convert your function-based generic views to class-based views.
Django 1.3 menambahkan dukungan tingkatan-kerangka kerja untuk modul logging
Python. Ini berarti anda dapat sekarang dengan mudah mengkonfigurasi dan mengendalikan pencatatan sebagai bagian dari proyek Django anda. Sejumlah penangan pencatatan dan pencatatan panggilan telah ditambahkan juga ke kode sendiri Django -- kebanyakan terutama, surel kesalahan dikirim pada kesalahan peladen HTTP 500 sekarang ditangani sebagai sebuah aktivitas pencatatan. Lihat the documentation on Django's logging interface untuk lebih rinci.
Django 1.3 dibekali dengan aplikasi bantuan baru -- django.contrib.staticfiles
-- untuk membantu pengembang manangani berkas-berkas media tetap (gambar, CSS, JavaScript, dll.) yang dibutuhkan untuk membangun sebuah halaman jaringan lengkap.
Di versi sebelummnya, itu adalah tempat umum untuk menempatkan aset tetap di MEDIA_ROOT
bersama dengan berkas-berkas diunggah-pengguna, dan melayani mereka kedua di MEDIA_URL
. Bagian dari tujuan untuk memperkenalkan aplikasi staticfiles
adalah untuk membuatnya lebih mudah menjaga berkas-berkas tetap terpisah dari berkas-berkas terunggah-pengguna. Aset tetap harus sekarang berada di subdirektori static/
dari aplikasi anda atau di direktori aset tetap lain terdaftar di STATICFILES_DIRS
, dan akan dilayani pada STATIC_URL
.
Lihat reference documentation of the app untuk lebih rinci atau pelajari bagaimana untuk manage static files.
unittest2
¶Python 2.7 introduced some major changes to the unittest
library,
adding some extremely useful features. To ensure that every Django
project can benefit from these new features, Django ships with a copy
of unittest2, a copy of the Python 2.7 unittest
library, backported
for Python 2.4 compatibility.
To access this library, Django provides the django.utils.unittest
module alias. If you are using Python 2.7, or you have installed
unittest2
locally, Django will map the alias to the installed
version of the unittest
library. Otherwise, Django will use its own
bundled version of unittest2
.
Untuk mengambil keuntungan dari nama lain ini, cukup gunakan:
from django.utils import unittest
dimanapun anda akan secara riwayat pakai:
import unittest
If you want to continue to use the base unittest
library, you can --
you just won't get any of the nice new unittest2
features.
Pengguna dari Python 2.5 dan diatas dapat sekarang menggunakan fungsi pengelolaan transaksi sebagai pengelola konteks. Sebagai contoh:
with transaction.autocommit():
# ...
ForeignKey
dan OneToOneField
sekarang menerima sebuah argumen on_delete
untuk menyesuaikan perilaku ketika obyek diacu dihapus. Sebelumnya, penghapusan selalu menurun; cara lain tersedia sekarang menyertakan setelan null, setel awalan, setel ke tiap tiap nilai, lindungi, atau tidak lakukan apa-apa.
Untuk informasi lebih, lihat dokumentasi on_delete
.
Untuk terjemahan dertan karakter dengan arti yang menyangsingkan, anda sekarang dapat menggunakan fungsi pgettext
untuk menentukan konteks dari deretan karakter.
Dan jika anda hanya ingin menambahkan beberapa informasi untuk penterjemah, anda dapat juga menambahkan komentar penterjemah khusus di sumber.
Untuk informasi lebih, lihat Contextual markers dan Komentar untuk penterjemah.
Sejumlah perbaikan telah dibuat pada etiket cetakan Django siap-pakai:
include
sekarang menerima sebuah pilihan with
, mengizinkan anda menentukan konteks variabel ke cetakan yang disertakaninclude
sekarang menerima sebuah pilihan only
, mengizinkan anda tidak menyertakan konteks saat ini dari konteks yang disertakan.with
sekarang mengizinkan anda menentukan banyak konteks variabel dalam blok with
tunggal.load
sekarang menerima sebuah argumen from
, mengizinkan anda memuat etiket tunggal atau penyaring dari sebuah pustaka.Itu dapat terkadang bermanfaat untuk mengizinkan penghias atau middleware untuk merubah sebuah tanggapan setelah itu telah dirancang oleh tampilan. Sebagai contoh, anda ingin merubah cetakan yang digunakan, atau menaruh data tambahan kedalam konteks.
Bagaimanapun, anda tidak dapat (dengan mudah) merubah isi dari dasar HttpResponse
setelah itu telah dibangun. Untuk menangani batasan ini, Django 1.3 menambahkan sebuah kelas TemplateResponse
baru. Tidak seperti obyek HttpResponse
, obyek TemplateResponse
menyimpan cetakan dan konteks yang telah disediakan oleh tampilan untuk menghitung tanggapan. Keluaran akhir dari tanggapan tidak dihitung sampai itu dibutuhkan, kemudian di pengolahan tanggapan.
Untul lebih rinci, lihat documentation pada kelas TemplateResponse
.
Django 1.3 melihat perkenalan dari beberapa perbaikan pada infrastruktur penyembunyian Django.
Pertama, Django sekarang mendukung banyak penyimpanan bernama. Di cara yang sama bahwa Django 1.2 diperkenalkan mendukung untuk hubungan abnyak basisdata, Django 1.3 mengizinkan anda menggunakan pengaturan CACHES
untuk menentukan banyak hubungan penyimpananbernama.
Yang kedua, versioning, site-wide prefixing dan transformation telah ditambahkan ke API tembolok.
Ketiga, cache key creation telah diperbaharui untuk mengambil deretan karakter permintaan kedalam akun pada permintaan GET
.
Akhirnya, sukungan untuk pylibmc telah ditambahkan ke backend tembolok memcached.
Untuk rincian lebih, lihat documentation on caching in Django.
Jika anda menyediakan backend otentifikasi penyesuaian dengan supports_inactive_user
disetel menjadi True
, sebuah instance User
tidak aktif akan memeriksa backend untuk perizinan. Ini sangat berguna untuk pemusatan penangan perizinan selanjutnya. Lihat authentication docs untuk lebih rinci.
Deretan percobaan GeoDjango sekarang disertakan ketika running the Django test suite dengan runtests.py
ketika menggunakan spatial database backends.
MEDIA_URL
dan STATIC_URL
harus berakhir di garis miring¶Sebelumnya, pengaturan MEDIA_URL
hanya membutuhkan buntutan garis miring jika itu mengandung sebuah akhiran diluar nama ranah.
Buntutan garis miring sekarang wajib untuk MEDIA_URL
dan pengaturan STATIC_URL
selama itu tidak kosong. Ini memastikan ada cara tetap untuk menggabungkan jalur di cetakan.
Pengaturan proyek yang menyediakan salah satu dari kedu apengaturan tanpa buntutan garis miring akan sekarang memunculkan sebuah PendingDeprecationWarning
.
Di Django 1.4 kondisi yang sama ini akan memunculkan DeprecationWarning
, dan di Django 1.5 akan memunculkan sebuah pengecualian ImproperlyConfigured
.
Django 1.1 dan 1.2 ditambahkan banyak tiket barang besar pada Django, seperti dukungan banyak-basisdata, pengecekan model, dan kerangka kerja pesan berdasarkan-sesi. Bagaimanapun, fokus ini pada fitur-fitur besar datang pada biaya banyak dari fitur-fitur terkecil.
Untuk mengimbangi ini, fokus dari pengeolahan pengembangan Django 1.3 telah menambahkan banyak dari terkecil, permintaan fitur yang sudah lama berjalan. Ini termasuk:
Site
saat ini di the sites framework.RequestFactory
untuk permintaan ejekan di percobaan.assertNumQueries()
-- membuatnya lebih mudah untuk mencoba aktivitas basisdata terkait dengan tampilan.list_filter
admin.mail_admins()
dan mail_managers()
sekarang mendukung dengan mudah melampirkan isi HTML pada pesan.EmailMessage
sekarang mendukung CC.simple_tag()
sekarang menerima sebuah argumen takes_context
, membuatnya lebih mudah untuk menulis etiket cetakan sederhana yang membutuhkan akses ke konteks cetakan.render()
baru -- sebuah jalan lain ke django.shortcuts.render_to_response()
menyediakan sebuah RequestContext
secara awal.F expressions
with timedelta
values when retrieving or updating database values.Sebelum Django 1.2.5, sistem pencegahan CSRF Django membebaskan permintaan AJAX dari pengecekan CSRF, karena security issues dilaporkan ke kami, bagaimanapun, semua permintaan sekarang ditujukan ke pengecekan CSRF. Obrolkan the Django CSRF documentation untuk rincian pada bagimana menangani pengecekan CSRF di permintaan AJAX.
Sebelum Django 1.2.5, antarmuka administratif Django mengizinkan menyaring pada bidang model apapun atau hubungan -- tidak hanya itu ditentukan di list_filter
-- melalui permintaan pengubahan deretan karakter. Karena masalah keamanan dilaporkan ke kami, bagaimanapun, permintaan argumen pencarian deretan karakter di admin harus untuk bidang atau hubungan ditentukan di list_filter
atau date_hierarchy
.
Dalam versi paling awal Django, ketika sebuah instance model mengandung sebuah FileField
dihapus, FileField
mengambil itu pada dirinya sendiri untuk juga menghapus berkas dari penyimpanan backend. Ini membuat pintu untuk beberapa kemungkinan skenario kehilangan-data serius, termasuk transaksi dikembalikan dan bidang-bidang pada model berbeda mengacu berkas sama. Di Django 1.3, ketika sebuah model dihapus metode delete()
FileField
tidak akan dipanggil. Jika anda butuh membersihkan berkas-berkas tidak bertuan, anda akan butuh menangani nya anda sendiri (sebagai contoh, dengan perintah pengelolaan penyesuaian yang dapat berjalan secara manual atau terjadwal untuk berjalan secara periodeik melalui sebagai contoh cron).
Widget formulir PasswordInput
, dimaksudkan untuk digunakan dengan bidang formulir yang mewakili sandi, menerima argumen kata kunci boolean render_value
menandakan apakah untuk mengirim datanya kembali ke peramban ketika menampilkan formulir yang diajukan dengan kesalahan. Sebelum pada Django 1.3, argumen ini diawalkan ke True
, berarti bahwa sandi diajukan harus dikirim kembali ke peramban sebagai bagian dari formulir. Pengembang yang berharap menambahkan sedikit keamanan tambahan dengan mengecualikan nilai itu dari formulir ditampilkan kembali dapat membuat instance PasswordInput`melewatkan ``render_value=False`
.+
Dikarenakan sensitif alamiah dari sandi, bagaimanapun, Django 1.3 mengambil langkah ini secara otomatis; nilai awalan dari render_value
sekarang False
, dan pengembang yang ingin nilai sandi dikembalikan ke peramban pada pengajuan dengan kesalahan (perilaku sebelumnya) harus secara tegas menunjukkan ini. Sebagai contoh:
class LoginForm(forms.Form):
username = forms.CharField(max_length=100)
password = forms.CharField(widget=forms.PasswordInput(render_value=True))
Django 1.3 sekarang menyertakan sebuah widget formulir ClearableFileInput
sebagai tambahan pada FileInput
. ClearableFileInput
dibangun dengan kotak centang untuk membersihkan nilai bidang (jika bidang mempunyai nilai dan tidak wajib), menyediakan tidak ada arti untuk membersihkan berkas yang ada dari FileField
.
ClearableFileInput
sekarang widget awalan untuk sebuah FileField
, jadi formulir yang ada termasuk FileField
tanpa memberikan widget penyesuaian akan butuh dipertanggungjawabkan untuk kemungkinan kotan centang tambahan di formulir keluaran yang dibangun.
Untuk kembali ke pembangunan sebelumnya (tanpa kemampuan membersihkan FileField
), gunakan widget FileInput
di tempat dari ClearableFileInput
. Sebagai contoh, di ModelForm
untuk hipotesis model Document
dengan sebuah FileField
bernama document
:
from django import forms
from myapp.models import Document
class DocumentForm(forms.ModelForm):
class Meta:
model = Document
widgets = {'document': forms.FileInput}
Sebelum pada Django 1.3, tabel basisdata digunakan oleh backend basisdata untuk sessions aplikasi tidak mempunyai indeks pada kolom expire_date
. Sebagai hasil, permintaan berdasarkan-tanggal pada tabel sesi -- seperti permintaan yang dibutuhkan untuk membersihkan sesi lama- akan menjadi sangat lambat jika ada banyak sesi.
Jika anda memiliki sebuah proyek yang ada yaitu menggunakan backend sesi basisdata, anda tidak harus melakukan apapun menampung perubahan ini. Bagaimanapun, anda mungkin mendapat dorongan penampilan yang signifikan jika anda secara manual menambahkan indeks baru ke tabel sesi. SQL yang akan menambah indeks dapat ditemukan dengan menjalankan perintah admin sqlindexes
:
python manage.py sqlindexes sessions
Django mempunyai riwayat disediakan (dan dipaksakan) daftar dari kata-kata kotor. Aplikasi komentar mempunyai daftar memaksa daftar ini dari kata-kata kotor, mencegah orang dari mengajukan komentar yang mengandung satu dari kata-kata kotor tersebut.
Sayangnya, teknik digunakan untuk menerapkan daftar carut marut ini menyedihkan dibuat-buat, dan cenderung pada Scunthorpe problem. Meningkatkan saringan siap-pakai untuk memperbaiki masalah ini akan membutuhkan usaha yang signifikan, dan sejak bahasa alam mengolah bukan ranah biasa dari kerangka kerja jaringan, kami telah "memperbaiki" masalah dengan membuat daftar dari daftar kosong kata-kata terlarang.
Jika anda ingin menyimpan kembali perilaku lama, cukup taruh pengaturan PROFANITIES_LIST
di berkas pengaturan anda yang menyertakan kata anda ingin larang (lihat commit that implemented this change jika anda ingin melihat kata-kata yang riwayatnya dilarang). Bagaimanapun, jika mengindari kata-kata kotor adalah penting bagi anda, anda akan disarankan mencari yang terbaik, sedikit pendekatan yang dibuat-buat pada masalah
Django 1.3 memperkenalkan perubahan bertentangan kebelakang berikut ke rasa lokal:
USStateField
telah diperluas untuk menyertakan kode pos Pasukan Bersenjata. Ini adakah bertentangan kebelakang jika anda bergantung pada USStateField
tidak menyertakan mereka.Di Django 1.3 perilaku pembuatan FormSet
adalah merubah sedikit. Secara riwayat kelas tidak membuat perbedaan diantara data tidak sedang dilewatkan dan sedang dilewatkan kamus kosong. Ini adalah tidak konsisten dengan perilaku di bagian lain dari kerangka kerja. Dimulai dengan 1.3 jika anda melewatkan di kamus kosong FormSet
akan memunculkan sebuah ValidationError
.
Sebagai contoh, dengan sebuah FormSet
:
>>> class ArticleForm(Form):
... title = CharField()
... pub_date = DateField()
>>> ArticleFormSet = formset_factory(ArticleForm)
kode berikut akan memunculkan sebuah ValidationError
:
>>> ArticleFormSet({})
Traceback (most recent call last):
...
ValidationError: [u'ManagementForm data is missing or has been tampered with']
Jika anda butuh untuk membuat obyek sebuah FormSet
kosong, jangan lewatkan di data atau gunakan None
:
>>> formset = ArticleFormSet()
>>> formset = ArticleFormSet(data=None)
Sebelumnya, callable di cetakan akan hanya dipanggil otomatis sebagai bagian dari pengolah keputusan variabel jika itu telah diambil melalui pencarian atribut. Ini adalah sebuah ketidakkonsistenan yang dapat menghasilkan kebingungan dan perilaku tidak membantu:
>>> Template("{{ user.get_full_name }}").render(Context({'user': user}))
u'Joe Bloggs'
>>> Template("{{ full_name }}").render(Context({'full_name': user.get_full_name}))
u'<bound method User.get_full_name of <...
Itu telah di selesaikan di Django 1.3 - hasil di kedua kasus akan menjadi u'Joe Bloggs'
. meskipun perilaku sebelumnya tidak berguna untuk bahasa cetakandirancang untuk perancang jaringan, dan tidak pernah sengaja didukung, itu memungkinkan bahwa beberapa cetakan mungkin rusak oleh perubahan ini.
Django menyediakan pengkaitan SQL penyesuaian sebagai sebuah cara untuk memasukkan SQL buah-tangan kedalam pengeolahan sinkronisasi basisdata. Satu dari kemungkinan penggunaan untuk penyesuaian SQL ini adalah memasukkan data kedalam basisdata anda. Jika SQL penyesuaian anda mengangund pernyataan INSERT
, pemasukan tersebut akan dilakukan setiap kali basisdata anda disinkronkan. Ini termasuk sinkronisasi dari tiap basisdata percobaan yang dibuat ketika anda menjalankan deretan percobaan.
Bagaimanapun, dalam pengolahan dari percobaan Django 1.3, itu ditemukan bahwa fitur ini tidak pernah lengkap bekerja seperti diiklan. Ketika menggunakan backend basisdata yang tidak mendukung transaksi, atau ketika menggunakan TransactionTestCase, data yang telah dimasukkan menggunakan SQL penyesuaian tidak akan nampak selama pengolahan percobaan.
Sayangnya, tidak ada cara untuk memperbaiki masalah ini tanpa memperkenalkan ketidaksesuaian kebelakang. Daripada membiarkan data inisial dimasukkan SQL di keadaan yang tidak menentu, Django sekarang memaksa kebijakan yang data dimasukkan oleh SQL penyesuaian tidak akan nampak selama percobaan.
Perubahan ini hanya mempengaruhi pengolahan percobaan. Anda masih dapat menggunakan SQL penyesuaian untuk memuat data kedalam basisdata produksi anda sebagai bagian dari pengolahan syncdb
. Jika anda membutuhkan data untuk ada selama kondisi percobaan, anda harus salah satu memasukkannya menggunakan test fixtures, atau menggunakan metode setUp()
dari kasus percobaan anda.
Pekerjaan telah diselesaikan untuk memudahkan, merasionalisasi dan algoritma dokumentasi yang sesuai digunakan oleh Django pada saat berjalan untuk membangun terjemahan dari terjemahan berbeda ditemukan di cakram, bernama:
Untuk harfiah dapat diterjemahkan ditemukan di kode Python dan cetakan (ranah gettext 'django'
)
INSTALLED_APPS
telah berubah. Untuk menyediakan sebuah perilaku yang tetap dengan bagian lain dari Django yang juga menggunakan pengaturan seperti itu (cetakan, dll) sekarang, ketika membangun terjemahan yang akan dibuat tersedia, aplikasi terdaftar pertama mempunyai hak lebih tinggi daripada satu terdaftar kemudian.LOCALE_PATHS
yang terjemahannya sekarang didahulukan lebih tinggi daripada terjemahan dari aplikasi INSTALLED_APPS
. Prioritas relatif diantara nilai-nilai terdaftar di pengaturan ini juga telah dirubah jadi jalur terdaftar dahulu mempunyai didahulukan lebih tinggi dari satu didaftar kemudian.locale
dari direktori mengandung pengaturan, yang biasanya bertepatan dengan dan dikenal sebagai direktori proyek sedang diusangkan di terbitan ini sebagai sebuah sumber dari terjemahan. (Yang didahulukan dari terjemahan ini adalah pertengahan diantara aplikasi dan terjemahan LOCALE_PATHS
). Lihat `corresponding deprecated features section`_dari dokumen ini.Untuk terjemahan harfiah ditemukan di kode JavaScript (ranah gettext 'djangojs'
):
'django'
: Menimpa terjemahan dikirim dengan aplikasi menggunakan pengaturan LOCALE_PATHS
sekarang memungkinkan untuk ranah ini juga. Terjemahan-terjemahan ini memiliki hak lebih tinggi daripada terjemahan dari paket-paket Python dilewatkan ke tampilan javascript_catalog()
. Jalur-jalur ditampilkan mempunyai hak lebih tinggi daripada satu yang ditampilkan kemudian.locale
dari direktori proyek belum pernah diperhitungkan untuk terjemahan JavaScript dan tetap di keadaan sama mempertimbangkan pengusangan untuk tempat tersebut.Ketika menggunakan transaksi dapat dikelola -- yaitu, apapun tetapi suasana autocommit awalan -- adalah terpenting ketika transaksi ditandai sebagai "dirty". Transaksi dirty diperbaiki oleh penghias commit_on_success
atau django.middleware.transaction.TransactionMiddleware
, dan commit_manually
memaksa mereka untuk ditutup secara eksplisit; membersihkan transaksi "get a pass", yang berarti mereka biasanya membatalkan transaksi pada akhir dari permintaan ketika hubungan ditutup.
Sampai Django 1.3, transaksi hanya ditandai dengan kotor ketika Django telah menyadari dari merubah tindakan yang dilakukan di mereka; yaitu baik beberapa model telah disimpan, beberapa perbaharuan dalam jumlah besar atau hapus telah dilakukan, atau pengguna secara eksplisit memanggil transaction.set_dirty()
. Di Django 1.3, sebuah transaksi ditandai kotor ketika tiap tindakan basisdata dilakukan.
Sebagai hasil dari perubahan ini, anda tidak lagi butuh menyetel transaksi kotor secara eksplisit ketika anda menjalankan SQL mentah atau menggunakan data-merubah SELECT
. Bagaimanapun, anda lakukan perlu secara eksplisit menutup tiap transaksi hanya-baca yang sedang diatur menggunakan commit_manually()
. Sebagai contoh:
@transaction.commit_manually
def my_view(request, name):
obj = get_object_or_404(MyObject, name__iexact=name)
return render_to_response('template', {'object':obj})
Sebelum Django 1.3, ini akan bekerja tanpa kesalahan. Bagaimanapun, dibawah Django 1.3, ini akan memunculkan sebuah TransactionManagementError
karena tindakan membaca yang mengambil instance MyObject
meninggalkan transaksi dalam keadaan kotor.
Sebelum Django 1.3, pengguna tidak aktif dapat meminta surel setel kembali sandi dan menyetel kembali sandi mereka. Di Django 1.3 pengguna tidak aktif akan menerima pesan sama sebagai sebuah akun yang tdak ada.
from_email
¶The django.contrib.auth.views.password_reset()
view now accepts a
from_email
parameter, which is passed to the password_reset_form
’s
save()
method as a keyword argument. If you are using this view with a
custom password reset form, then you will need to ensure your form's save()
method accepts this keyword argument.
Django 1.3 mengusangkan beberapa fitur dari terbitan lebih awal. Fitur-fitur ini masih didukung, tetapi akan bertahapdihapus terhadap siklus terbitan selanjutnya.
Kode mengambil keuntungan dari tiap fitur dibawah ini akan memunculkan sebuah PendingDeprecationWarning
di Django 1.3. Peringatan ini akan diam secara awalan, tetapi mungkin berubah menggunakan modul warnings
Python, atau dengan menjalankan Python dengan sebuah bendera -Wd
atau -Wall
.
Di Django 1.4, peringatan ini akan menjadi DeprecationWarning
, yang tidak diam. Di Django 1.5 mendukung untuk fitur-fitur ini akan dipindahkan sepenuhnya.
lihat juga
Untuk rincian lebih, lihat dokumentasi Django's release process dan deprecation timeline kami.
mod_python
¶Pustaka mod_python
belum mempunyai terbitan sejak 2007 atau perbaikan sejak 2008. Badan Apache Foundation memilih untuk memindahkan mod_python
dari kumpulan dari proyek aktif di gudang kendali versinya, dan pimpinan pengembangnya telah mengganti semua usahanya menuju lebih ringan, ramping, lebih stabil, dan lebih fleksibel backend mod_wsgi
.
Jika anda saat ini menggunakan penangan permintaan mod_python
, anda harus menyebarkan kembali proyek Django anda menggunakan penangan permintaan lain. mod_wsgi adalah penangan permintaan dianjurkan oleh proyek Django, tetapi FastCGI juga didukung. Dukungan untuk penyebaran mod_python
akan dipindahkan di Django 1.5.
Sebagai hasil dari perkenalan dari tampilan umum berdasarkan-kelas, tampilan umum berdasarkan fungsi disediakan oleh Django telah diusangkan. Modul-modul berikut dan tampilan mereka kandung telah diusangkan:
django.views.generic.create_update
django.views.generic.date_based
django.views.generic.list_detail
django.views.generic.simple
template
¶Obyek test client returns Response
Django diberi keterangan dengan informasi percobaan tambahan. Di Django versi sebelum 1.3, ini menyertakan atribut template
mengandung informasi tentang cetakan dibangun dalam membangkitkan tanggapan: baik None, obyek Template
tunggal, atau daftar dari obyek Template
. Ketidakkonsistenan ini mengembalikan nilai (terkadang daftar, terkadang bukan) membuat atribut sulit bekerja dengannya.
Di Django 1.3 atribut template
diusangkan dalam mendukung dari atribut templates
baru, yang selalu sebuah daftar, bahkan jika itu hanya mempunyai unsur tunggal atau tidak ada unsur.
DjangoTestRunner
¶As a result of the introduction of support for unittest2
, the features
of django.test.simple.DjangoTestRunner
(including fail-fast
and Ctrl-C test termination) have been made redundant. In view of this
redundancy, DjangoTestRunner
has been turned into an empty placeholder
class, and will be removed entirely in Django 1.5.
url
dan ssi
¶Kebanyakan etiket cetakan akan mengizinkan untuk melewati di baik ketetapan atau variabel sebagai argumen -- sebagai contoh:
{% extends "base.html" %}
mengizinkan anda menentukan cetakan dasar sebagai ketetapan, tetapi jika anda mempunyai variabel konteks templ
yang mengandung nilai base.html
:
{% extends templ %}
juga sah.
Bagaimanapun, karena sebuah kecelakan dari sejarah, url
dan ssi
adalah berbeda. Etiket ini menggunakan kedua, sintaksis tanpa dikutip, tetapi menafsirkan argumen sebagai ketetapan. Ini berarti itu tidak memungkinkan menggunakan konteks variabel sebagai sasaran dari etiket url
dan ssi
.
Django 1.3 menandai mulai pengolahan untuk memperbaiki riwayat kecelakaan. Django 1.3 menambahkan pustaka cetakan baru -- future
yang menyediakan penerapan lain dari etiket cetakan url
dan ssi
. Pustaka future
ini menerapkan perilaku yang membuat penanganan dari argumen pertama tetap dengan penanganan dari semua variabel lain. Jadi, sebuah cetakan yang ada yang mengandung:
{% url sample %}
harus diganti dengan:
{% load url from future %}
{% url 'sample' %}
Etiket yang menerapkan perilaku lama telah diusangkan, dan di Django 1.5, perilaku lama akan diganti dengan perilaku baru. Untuk memastikan kesesuaian dengan versi selanjutnya dari Django, cetakan yang ada harus dirubah menggunakan pustaka-pustaka future
dan sintaksis baru.
Di versi aplikasi admin sebelumnya menentukan metode masuk di banyak tempat dan mengabaikan hampir penerapan mirip di aplikasi otentifikasi yang sudah digunakan. Efek samping dari penggandaan ini adalah kehilangan pemakaian dari perubahan dibuat di r12634 untuk mendukung kumpulan lebih luas dari karakter untuk nama pengguna.
Terbitan ini refaktor mekanisme masuk admin untuk menggunakan subkelas dari AuthenticationForm
daripada pengesahan formulir manual. Cara tidak terdokumentasi sebelumnya 'django.contrib.admin.sites.AdminSite.display_login_form'
telah diusangkan dalam mendukung dari atribut login_form
baru.
reset
dan sqlreset
¶Perintah-perintah tersebut telah diusangkan. Perintah flush
dan sqlflush
dapat digunakan untuk menghapus apapun. Anda dapat juga menggunakan pernyataan ALTER TABLE atau DROP TABLE secara manual.
TEST_RUNNER
berdasarkan-fungsi sebelumnya digunakan untuk menjalankan deretan percobaan GeoDjango, django.contrib.gis.tests.run_gis_tests
, akhirnya diusangkan dalam mendukung pejalan percobaan berdasarkan kelas, django.contrib.gis.tests.GeoDjangoTestSuiteRunner
.transform()
akan secara diam tidak melakukan apapun ketika GDAL tidak tersedia. Sekarang GEOSException
secara pantas dimunculkan untuk menunjukkan kemungkinan kegagalan kode aplikasi. Sebuah peringatan sekarang dimunculkan jika transform()
dipanggil ketika SRID dari geometri kurang dari 0 atau None
CZBirthNumberField.clean
¶Sebelumnya metode clean()
bidang ini menerima kedua, kelamin, argumen yang mengizinkan pemeriksanaan pengesahan lebih kuat untuk dibuat, bagaimanapun sejak argumen ini dapat tidak pernah sebenarnya dilewatkan dari mesin-mesin formulir Django itu sekarang ditunda pengusangan.
CompatCookie
¶Sebelumnya, django.http
membedah sebuah kelas CompatCookie
tidak didokumentasikan, yang merupakan pembungkus perbaikan kesalahan disekitar pustaka standar SimpleCookie
. Ketika perbaikan dipindahkan ke hulu, ini sekarang diusangkan - anda harus menggunakan from django.http import SimpleCookie
sebagai gantinya.
Terbitan dari Django memulai pengolahan pengusangan untuk penyertaan dari terjemahan ditempatkan dibawah disebut jalur proyek di pengolahan membangun terjemahan dilakukan pada saat runtime. Pengaturan LOCALE_PATHS
dapat digunakan untuk tugas yang sama dengan menambahkan jalur sistem berkas pada direktori locale
mengandung terjemahan tingkatan-proyek pada nilai dari pengaturan itu.
Alasan untuk keputusan ini:
jalur proyek selalu konsep ditentukan longgar (sebenarnya, direktori digunakan untuk menempatkan tingkat-proyek terjemahan adalah direktori mengandung pengaturan modul) dan telah ada pergantian di bagian lain dari kerangka kerja untuk menghentikan menggunakan itu sebagai sebuah acuan untuk tempat dari aset pada waktu berjalan.
Penemuan dari subdirektori locale
cenderung gagal ketika menyebarkan skenario adalah lebih rumit daripada satu yang dasar. sebagai contoh dia gagal ketika modul pengaturan adalah sebuah direktori (tiket #10765).
Terdapat kemungkinan pengembangan aneh- dan penyebaran- masalah waktu seperti fakta bahwa subdirektori project_dir/locale/
daapt membangkitkan pesan-pesan kesalahan tiruan ketika direktori proyek ditambahkan ke jalur Python (manage.py runserver
melakukan ini) dan kemudian itu bentrok dengan modul pustaka standar dinamai sama, ini adalah pesan kesalahan khas:
/usr/lib/python2.6/gettext.py:49: ImportWarning: Not importing directory '/path/to/project/locale': missing __init__.py.
import locale, copy, os, re, struct, sys
Tempat ini tidak disertakan di pengeolahan membangun terjemahan untuk harfiah JavaScript. Pengusangan ini memindahkan ketidakkonsistenan itu.
PermWrapper
dipindah ke django.contrib.auth.context_processors
¶Di Django 1.2, kami mulai mengolah dari merubah tempat dari pengolah konteks auth
dari django.core.context_processors
menjadi django.contrib.auth.context_processors
. Bagaimanapun, PermWrapper``mendukung kelas adalah kesalahan dihilangkan dari perpindahan itu. Di Django 1.3, kelas ``PermWrapper
juga dipindahkan ke django.contrib.auth.context_processors
, bersama dengan kelas pendukung PermLookupDict
. Kelas-kelas baru secara kegunaan mirip pada versi lama mereka; hanya tempat modul yang berubah.
XMLField
¶Ketika Django pertama kali diterbitkan, Django menyertakan sebuah XMLField
yang melakukan pengecekan XML otomatis untuk tiap bidang masukan. Bagaimanapun, fungsi pengecekan ini belum dilakukan sejak perkenalan dari newforms
, sebelum pada terbitan 1.0. Sebagai hasil, XMLField
sebagai TextField
.
Untuk alasan ini, Django 1.3 mempunyai jalur-cepat pengusangan dari XMLField
-- sebagai ganti dua-terbitan pengusangan, XMLField
akan dipindahkan seluruhnya di Django 1.4.
Itu sangat mudah memperbaharui kode anda untuk menampung perubahan ini -- cukup ganti semua penggunaan dari XMLField
dengan``TextField``, dan pindahkan argumen kata kunci schema_path
(jika itu ditentukan).
Des 02, 2019