--- title: "Catatan terbitan Django 1.3" version: 2.2 locale: id source: https://docs.djangoproject.com/id/2.2/releases/1.3/ canonical: https://djangodocs.dev/id/2.2/releases/1.3/ --- # 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](#whats-new-1-3) 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](#backwards-incompatible-changes-1-3) 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: - Sebuah kerangka untuk menulis [tampilan berbasis-kelas](#class-based-views). - Dukungan siap-pakai untuk [using Python's logging facilities](#logging). - Dukungan bantuan untuk [easy handling of static files](#extended-static-files-handling). - Kerangka kerja percobaan Django sekarang mendukung (dan dibekali dengan salinan dari) [the unittest2 library](#unittest2-support). Sedapat mungkin, tentu saja, fitur-fitur baru diperkenalkan di sikap kesesuaian-kebelakang per kebijakan [our API stability policy](/id/2.2/misc/api-stability/). Sebagai hasil dari kebijakan ini, Django 1.3 [begins the deprecation process for some features](#deprecated-features-1-3). ## 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. Lihat [the documentation on class-based generic views](/id/2.2/topics/class-based-views/) untuk lebih rinci. Ada juga sebuah dokumen untuk membantu anda [convert your function-based generic views to class-based views](https://docs.djangoproject.com/en/1.4/topics/generic-views-migration/). ### Pencatatan 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](/id/2.2/topics/logging/) untuk lebih rinci. ### 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`](/id/2.2/ref/settings/#std-setting-MEDIA_ROOT) bersama dengan berkas-berkas diunggah-pengguna, dan melayani mereka kedua di [`MEDIA_URL`](/id/2.2/ref/settings/#std-setting-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`](/id/2.2/ref/settings/#std-setting-STATICFILES_DIRS), dan akan dilayani pada [`STATIC_URL`](/id/2.2/ref/settings/#std-setting-STATIC_URL). Lihat [reference documentation of the app](/id/2.2/ref/contrib/staticfiles/) untuk lebih rinci atau pelajari bagaimana untuk [manage static files](/id/2.2/howto/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](https://pypi.org/project/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`](/id/2.2/ref/models/fields/#django.db.models.ForeignKey) dan [`OneToOneField`](/id/2.2/ref/models/fields/#django.db.models.OneToOneField) sekarang menerima sebuah argumen [`on_delete`](/id/2.2/ref/models/fields/#django.db.models.ForeignKey.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`](/id/2.2/ref/models/fields/#django.db.models.ForeignKey.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](/id/2.2/topics/i18n/translation/#contextual-markers) dan [Komentar untuk penterjemah](/id/2.2/topics/i18n/translation/#translator-comments). ### Perbaikan pada etiket cetakan siap-pakai Sejumlah perbaikan telah dibuat pada etiket cetakan Django siap-pakai: - Etiket [`include`](/id/2.2/ref/templates/builtins/#std-templatetag-include) sekarang menerima sebuah pilihan `with`, mengizinkan anda menentukan konteks variabel ke cetakan yang disertakan - Etiket [`include`](/id/2.2/ref/templates/builtins/#std-templatetag-include) sekarang menerima sebuah pilihan `only`, mengizinkan anda tidak menyertakan konteks saat ini dari konteks yang disertakan. - Etiket [`with`](/id/2.2/ref/templates/builtins/#std-templatetag-with) sekarang mengizinkan anda menentukan banyak konteks variabel dalam blok [`with`](/id/2.2/ref/templates/builtins/#std-templatetag-with) tunggal. - Etiket [`load`](/id/2.2/ref/templates/builtins/#std-templatetag-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`](/id/2.2/ref/request-response/#django.http.HttpResponse) setelah itu telah dibangun. Untuk menangani batasan ini, Django 1.3 menambahkan sebuah kelas [`TemplateResponse`](/id/2.2/ref/template-response/#django.template.response.TemplateResponse) baru. Tidak seperti obyek [`HttpResponse`](/id/2.2/ref/request-response/#django.http.HttpResponse), obyek [`TemplateResponse`](/id/2.2/ref/template-response/#django.template.response.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](/id/2.2/ref/template-response/) pada kelas [`TemplateResponse`](/id/2.2/ref/template-response/#django.template.response.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`](/id/2.2/ref/settings/#std-setting-CACHES) untuk menentukan banyak hubungan penyimpananbernama. Yang kedua, [versioning](/id/2.2/topics/cache/#cache-versioning), [site-wide prefixing](/id/2.2/topics/cache/#cache-key-prefixing) dan [transformation](/id/2.2/topics/cache/#cache-key-transformation) telah ditambahkan ke API tembolok. Ketiga, [cache key creation](/id/2.2/topics/cache/#using-vary-headers) telah diperbaharui untuk mengambil deretan karakter permintaan kedalam akun pada permintaan `GET`. Akhirnya, sukungan untuk [pylibmc](http://sendapatch.se/projects/pylibmc/) telah ditambahkan ke backend tembolok memcached. Untuk rincian lebih, lihat [documentation on caching in Django](/id/2.2/topics/cache/). ### 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](/id/2.2/topics/auth/) untuk lebih rinci. ### GeoDjango Deretan percobaan GeoDjango sekarang disertakan ketika [running the Django test suite](/id/2.2/internals/contributing/writing-code/unit-tests/#running-unit-tests) dengan `runtests.py` ketika menggunakan [spatial database backends](/id/2.2/ref/contrib/gis/db-api/#spatial-backends). ### [`MEDIA_URL`](/id/2.2/ref/settings/#std-setting-MEDIA_URL) dan [`STATIC_URL`](/id/2.2/ref/settings/#std-setting-STATIC_URL) harus berakhir di garis miring Sebelumnya, pengaturan [`MEDIA_URL`](/id/2.2/ref/settings/#std-setting-MEDIA_URL) hanya membutuhkan buntutan garis miring jika itu mengandung sebuah akhiran diluar nama ranah. Buntutan garis miring sekarang *wajib* untuk [`MEDIA_URL`](/id/2.2/ref/settings/#std-setting-MEDIA_URL) dan pengaturan [`STATIC_URL`](/id/2.2/ref/settings/#std-setting-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](/id/2.2/releases/1.1/) dan [1.2](/id/2.2/releases/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`](/id/2.2/ref/contrib/sites/#django.contrib.sites.models.Site) saat ini di [the sites framework](/id/2.2/ref/contrib/sites/). - [`RequestFactory`](/id/2.2/topics/testing/advanced/#django.test.RequestFactory) untuk permintaan ejekan di percobaan. - Pernyataan percobaan baru -- [`assertNumQueries()`](/id/2.2/topics/testing/tools/#django.test.TransactionTestCase.assertNumQueries) -- membuatnya lebih mudah untuk mencoba aktivitas basisdata terkait dengan tampilan. - Mendukung untuk pencarian mencangkup hubungan di [`list_filter`](/id/2.2/ref/contrib/admin/#django.contrib.admin.ModelAdmin.list_filter) admin. - Support for [HttpOnly](https://www.owasp.org/index.php/HttpOnly) cookies. - [`mail_admins()`](/id/2.2/topics/email/#django.core.mail.mail_admins) dan [`mail_managers()`](/id/2.2/topics/email/#django.core.mail.mail_managers) sekarang mendukung dengan mudah melampirkan isi HTML pada pesan. - [`EmailMessage`](/id/2.2/topics/email/#django.core.mail.EmailMessage) sekarang mendukung CC. - Surel kesalahan sekarang menyertakan lebih rinci dan berbentuk dari halaman kesalahan peladen pencari kesalahan. - [`simple_tag()`](/id/2.2/howto/custom-template-tags/#django.template.Library.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()`](/id/2.2/topics/http/shortcuts/#django.shortcuts.render) baru -- sebuah jalan lain ke `django.shortcuts.render_to_response()` menyediakan sebuah [`RequestContext`](/id/2.2/ref/templates/api/#django.template.RequestContext) secara awal. - Support for combining [`F expressions`](/id/2.2/ref/models/expressions/#django.db.models.F) 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](https://www.djangoproject.com/weblog/2011/feb/08/security/) dilaporkan ke kami, bagaimanapun, *semua* permintaan sekarang ditujukan ke pengecekan CSRF. Obrolkan [the Django CSRF documentation](/id/2.2/ref/csrf/) 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`](/id/2.2/ref/models/fields/#django.db.models.FileField) dihapus, [`FileField`](/id/2.2/ref/models/fields/#django.db.models.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`](/id/2.2/ref/models/fields/#django.db.models.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`](/id/2.2/ref/forms/widgets/#django.forms.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`](/id/2.2/ref/forms/widgets/#django.forms.ClearableFileInput) sebagai tambahan pada [`FileInput`](/id/2.2/ref/forms/widgets/#django.forms.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](/id/2.2/topics/http/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 ``` ### 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](https://en.wikipedia.org/wiki/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](https://code.djangoproject.com/changeset/13996) 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 ### 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`. 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) ``` ### Callable di cetakan 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. ### 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](/id/2.2/topics/testing/tools/#topics-testing-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`](/id/2.2/ref/settings/#std-setting-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`](/id/2.2/ref/settings/#std-setting-LOCALE_PATHS) yang terjemahannya sekarang didahulukan lebih tinggi daripada terjemahan dari aplikasi [`INSTALLED_APPS`](/id/2.2/ref/settings/#std-setting-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`](/id/2.2/ref/settings/#std-setting-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`](/id/2.2/ref/settings/#std-setting-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`](/id/2.2/ref/exceptions/#django.db.transaction.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`](https://docs.python.org/3/library/warnings.html#module-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. > **See also** > > Untuk rincian lebih, lihat dokumentasi [Django's release process](/id/2.2/internals/release-process/) dan [deprecation timeline](/id/2.2/internals/deprecation/) 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](/id/2.2/howto/deployment/wsgi/modwsgi/) 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](/id/2.2/topics/testing/tools/#test-client) returns [`Response`](/id/2.2/topics/testing/tools/#django.test.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`](/id/2.2/ref/templates/api/#django.template.Template) tunggal, atau daftar dari obyek [`Template`](/id/2.2/ref/templates/api/#django.template.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`](/id/2.2/topics/testing/tools/#django.test.Response.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` 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. ### Perubahan ke cara masuk dari admin 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](https://code.djangoproject.com/changeset/12634) untuk mendukung kumpulan lebih luas dari karakter untuk nama pengguna. Terbitan ini refaktor mekanisme masuk admin untuk menggunakan subkelas dari [`AuthenticationForm`](/id/2.2/topics/auth/default/#django.contrib.auth.forms.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`](/id/2.2/ref/contrib/admin/#django.contrib.admin.AdminSite.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`](/id/2.2/ref/settings/#std-setting-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()`](/id/2.2/ref/contrib/gis/geos/#django.contrib.gis.geos.GEOSGeometry.transform) akan secara diam tidak melakukan apapun ketika GDAL tidak tersedia. Sekarang [`GEOSException`](/id/2.2/ref/contrib/gis/geos/#django.contrib.gis.geos.GEOSException) secara pantas dimunculkan untuk menunjukkan kemungkinan kegagalan kode aplikasi. Sebuah peringatan sekarang dimunculkan jika [`transform()`](/id/2.2/ref/contrib/gis/geos/#django.contrib.gis.geos.GEOSGeometry.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`](/id/2.2/ref/settings/#std-setting-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. ### 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`](/id/2.2/ref/models/fields/#django.db.models.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).