Catatan terbitan Django 1.3

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.

Ikhtisar

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:

Wherever possible, new features are introduced in a backwards-compatible manner per our API stability policy policy. As a result of this policy, Django 1.3 begins the deprecation process for some features.

Kesesuaian Python

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.

Apa yang baru di Django 1.3

Tampilan berdasarkan-kelas

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.

See the documentation on class-based generic views for more details. There is also a document to help you convert your function-based generic views to class-based views.

Pencatatan

Django 1.3 adds framework-level support for Python's logging module. This means you can now easily 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 an HTTP 500 server error are now handled as a logging activity. See the documentation on Django's logging interface for more details.

Memperpanjang penanganan berkas tetap

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.

Dukungan 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.

Pengelola konteks transaksi

Pengguna dari Python 2.5 dan diatas dapat sekarang menggunakan fungsi pengelolaan transaksi sebagai pengelola konteks. Sebagai contoh:

with transaction.autocommit():
    ...

Dapat dikonfigurasi hapus-menurun

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.

Penanda kontekstual dan komentar untuk deretan karakter dapat diterjemahkan

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.

Perbaikan pada etiket cetakan siap-pakai

Sejumlah perbaikan telah dibuat pada etiket cetakan Django siap-pakai:

  • Etiket include sekarang menerima sebuah pilihan with, mengizinkan anda menentukan konteks variabel ke cetakan yang disertakan

  • Etiket include sekarang menerima sebuah pilihan only, mengizinkan anda tidak menyertakan konteks saat ini dari konteks yang disertakan.

  • Etiket with sekarang mengizinkan anda menentukan banyak konteks variabel dalam blok with tunggal.

  • Etiket load sekarang menerima sebuah argumen from, mengizinkan anda memuat etiket tunggal atau penyaring dari sebuah pustaka.

TemplateResponse

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.

Perubahan menemblok

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.

Perizinan untuk pengguna tidak aktif

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.

GeoDjango

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.

Yang lainnya

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:

  • Peningkatan alat-alat untuk mengakses dan merubah obyek Site saat ini di the sites framework.

  • RequestFactory untuk permintaan ejekan di percobaan.

  • Pernyataan percobaan baru -- assertNumQueries() -- membuatnya lebih mudah untuk mencoba aktivitas basisdata terkait dengan tampilan.

  • Mendukung untuk pencarian mencangkup hubungan di list_filter admin.

  • Support for HttpOnly cookies.

  • mail_admins() dan mail_managers() sekarang mendukung dengan mudah melampirkan isi HTML pada pesan.

  • EmailMessage sekarang mendukung CC.

  • Surel kesalahan sekarang menyertakan lebih rinci dan berbentuk dari halaman kesalahan peladen pencari kesalahan.

  • simple_tag() sekarang menerima sebuah argumen takes_context, membuatnya lebih mudah untuk menulis etiket cetakan sederhana yang membutuhkan akses ke konteks cetakan.

  • Jalan pintas render() baru -- sebuah jalan lain ke django.shortcuts.render_to_response() menyediakan sebuah RequestContext secara awal.

  • Support for combining F expressions with timedelta values when retrieving or updating database values.

Perubahan bertentangan kebelakang di 1.3

Pengesahan CSRF sekarang berlaku pada permintaan AJAX

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.

Batasan penyaring di antarmuka admin

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.

Menghapus model tidak menghapus berkas terhubung

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).

Perilaku membangun awalan PasswordInput

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))

Dapat dibersihkan widget awalan untuk FileField

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}

Indeks baru pada tabel sesi basisdata

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.

If you have an existing project that is using the database session backend, you don't have to do anything to accommodate this change. However, you may get a significant performance boost if you manually add the new index to the session table. The SQL that will add the index can be found by running the sqlindexes admin command:

python manage.py sqlindexes sessions

Tidak ada lagi kata nakal

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.

If you want to restore the old behavior, simply put a PROFANITIES_LIST setting in your settings file that includes the words that you want to prohibit (see the commit that implemented this change if you want to see the list of words that was historically prohibited). However, if avoiding profanities is important to you, you would be well advised to seek out a better, less naive approach to the problem.

Perubahan rasa lokal

Django 1.3 memperkenalkan perubahan bertentangan kebelakang berikut ke rasa lokal:

  • Canada (ca) -- Propinsi "Newfoundland and Labrador" telah mempunyai kode propinsinya diperbaharui menjadi "NL", daripada yang lama "NF". Sebagai tambahan, Yukon Territory telah mempunyai kode propinsinya diralat menjadi "YT", daripada "YK".

  • Indonesia (id) -- Propinsi "Nanggroe Aceh Darussalam (NAD)" telah dipindahkan dari daftar propinsi dalam mendukung dari penyebutan resmi baru "Aceh (ACE)".

  • United States of America (us) -- Daftar dari "states" digunakan oleh USStateField telah diperluas untuk menyertakan kode pos Pasukan Bersenjata. Ini adakah bertentangan kebelakang jika anda bergantung pada USStateField tidak menyertakan mereka.

Perbaharuan FormSet

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.

For example with a FormSet:

>>> class ArticleForm(Form):
...     title = CharField()
...     pub_date = DateField()
...
>>> ArticleFormSet = formset_factory(ArticleForm)

the following code will raise a ValidationError:

>>> ArticleFormSet({})
Traceback (most recent call last):
...
ValidationError: [u'ManagementForm data is missing or has been tampered with']

if you need to instantiate an empty FormSet, don't pass in the data or use None:

>>> formset = ArticleFormSet()
>>> formset = ArticleFormSet(data=None)

Callable di cetakan

Previously, a callable in a template would only be called automatically as part of the variable resolution process if it was retrieved via attribute lookup. This was an inconsistency that could result in confusing and unhelpful behavior:

>>> 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.

Penggunaan SQL penyesuaian untuk memuat data inisial di percobaan

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.

Dirubah prioritas dari memuat terjemahan

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')

  • Keutamaan dari terjemahan disertakan dengan aplikasi terdaftar di pengaturan 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.

  • Sekarang itu dimungkinkan menimpa terjemahan dibekali dengan aplikasi dengan menggunakan pengaturan 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.

  • Subdirektori 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'):

  • Mirip pada terjemahan ranah '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.

  • Terjemahan dibawah subdirektori locale dari direktori proyek belum pernah diperhitungkan untuk terjemahan JavaScript dan tetap di keadaan sama mempertimbangkan pengusangan untuk tempat tersebut.

Pengelolaan transaksi

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.

Tidak ada penyetelan kembali sandi untuk pengguna tidak aktif

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.

Tampilan penyetelan ulang sandi sekarang menerima 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.

Fitur usang di 1.3

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.

dukungan 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.

Tampilan umum berdasarkan-fungsi

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

Percobaan klien tanggapan atribut 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.

Dirubah ke url dan ssi

Most template tags will allow you to pass in either constants or variables as arguments -- for example:

{% extends "base.html" %}

allows you to specify a base template as a constant, but if you have a context variable templ that contains the value 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 marks the start of the process to correct this historical accident. Django 1.3 adds a new template library -- future -- that provides alternate implementations of the url and ssi template tags. This future library implement behavior that makes the handling of the first argument consistent with the handling of all other variables. So, an existing template that contains:

{% url sample %}

should be replaced with:

{% 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.

Perubahan ke cara masuk dari 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.

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.

Perintah pengelolaan 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.

GeoDjango

  • 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.

  • Sebelumnya, memanggil 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.

Memuat penterjemahan tingkatan-proyek

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).

  • There are potential strange development- and deployment-time problems like the fact that the project_dir/locale/ subdir can generate spurious error messages when the project directory is added to the Python path (manage.py runserver does this) and then it clashes with the equally named standard library module, this is a typical warning message:

    /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.

Perpindahan 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).

Catatan terbitan Django 1.3.1
Catatan terbitan Django 1.2.7
Back to Top