Catatan terbitan Django 1.0

Selamat datang di Django 1.0!

We’ve been looking forward to this moment for over three years, and it’s finally here. Django 1.0 represents the largest milestone in Django’s development to date: a Web framework that a group of perfectionists can truly be proud of.

Django 1.0 mewakili lebih 3 tahun dari pengembangan komunitas sebagai proyek Sumber Terbuka. Django menerima bantuan dari ribuan pengembang, telah diterjemahkan kedalam 50 bahasa, dan hari ini digunakan oleh pengembang pada setiap benua dan dalam setiap macam pekerjaan.

Sebuah catatan riwayat menarik: ketika Django pertama kali terbit di Juli 2005, versi terbitan awal dari Django datang dari gudang internal pada angka perbaikan 8825. Django 1.0 mewakili perbaikan 8961 dari gudang umum kami. Dia kelihatannya sesuai bahwa terbitan 1.0 kami datang pada saat dimana bantuan komunitas mengambil alih yang dibuat secara pribadi.

Stability and forwards-compatibility

The release of Django 1.0 comes with a promise of API stability and forwards-compatibility. In a nutshell, this means that code you develop against Django 1.0 will continue to work against 1.1 unchanged, and you should need to make only minor changes for any 1.X release.

Lihat Panduan stabilitas API untuk rincian penuh.

Perubahan kesesuaian-kebelakang

Django 1.0 mempunyai sejumlah perubahan kesesuaian-kebelakang dari Django 0.96. Jika anda mempunyai aplikasi ditulis terhadap Django 0.96 yang anda butuh menautkannya, lihat panduan tautan rincian kami:

Daftar lengkap dari perubahan kesesuaian-kebelakang dapat ditemukan pada https://code.djangoproject.com/wiki/BackwardsIncompatibleChanges.

Apa yang baru di Django 1.0

banyak!

Sejak Django 0.96, kami telah membuat lebih 4,000 kode penyerahan, memperbaiki lebih dari 2,000 kesalahan, dan menyunting, menambahkan, atau memindahkan sekitar 350,000 baris kode. Kami juga telah menambahkan 40,000 baris dari dokumentasi baru, dan secara hebat meningkatkan apa yang telah ada disana.

Sebenarnya, dokumentasi baru adalah satu dari fitur kesukaan kami dari Django 1.0, jadi kami mungkin juga mulai disana. Pertama, terdapat situs dokumentasi baru:

Dokumentasi telah sangat ditingkatkan, dibersihkan, dan umumnya dibuat mengagumkan. Sekarang terdapat pencarian khusus, indeks, dan lebih.

Kami tidak dapat mungkin mendokumentasikan semuanya yang baru dalam 1.0, tetapi dokumentasi akan menjadi panduan pasti anda. Dimanapun anda melihat sesuatu seperti:

New in Django 1.0:

Fitur ini baru di Django 1.0

Anda akan mengetahui bahwa anda mencari sesuatu baru atau berubah.

Sorotan utama lain dari Django 1.0 adalah:

Re-factored admin application

The Django administrative interface (django.contrib.admin) has been completely refactored; admin definitions are now completely decoupled from model definitions (no more class Admin declaration in models!), rewritten to use Django’s new form-handling library (introduced in the 0.96 release as django.newforms, and now available as simply django.forms) and redesigned with extensibility and customization in mind. Full documentation for the admin application is available online in the official Django documentation:

Lihat acuan admin untuk rinci

Improved Unicode handling

Django’s internals have been refactored to use Unicode throughout; this drastically simplifies the task of dealing with non-Western-European content and data in Django. Additionally, utility functions have been provided to ease interoperability with third-party libraries and systems which may or may not handle Unicode gracefully. Details are available in Django’s Unicode-handling documentation.

Lihat Unicode data.

ORM yang dikembangkan

Django’s object-relational mapper – the component which provides the mapping between Django model classes and your database, and which mediates your database queries – has been dramatically improved by a massive refactoring. For most users of Django this is backwards-compatible; the public-facing API for database querying underwent a few minor changes, but most of the updates took place in the ORM’s internals. A guide to the changes, including backwards-incompatible modifications and mentions of new features opened up by this refactoring, is available on the Django wiki.

Automatic escaping of template variables

To provide improved security against cross-site scripting (XSS) vulnerabilities, Django’s template system now automatically escapes the output of variables. This behavior is configurable, and allows both variables and larger template constructs to be marked as safe (requiring no escaping) or unsafe (requiring escaping). A full guide to this feature is in the documentation for the autoescape tag.

django.contrib.gis (GeoDjango)

A project over a year in the making, this adds world-class GIS (Geographic Information Systems) support to Django, in the form of a contrib application. Its documentation is currently being maintained externally, and will be merged into the main Django documentation shortly. Huge thanks go to Justin Bronn, Jeremy Dunck, Brett Hoerner and Travis Pinney for their efforts in creating and completing this feature.

Lihat http://geodjango.org/ untuk rincian.

Pluggable file storage

Django’s built-in FileField and ImageField now can take advantage of pluggable file-storage backends, allowing extensive customization of where and how uploaded files get stored by Django. For details, see the files documentation; big thanks go to Marty Alchin for putting in the hard work to get this completed.

Kesesuaian Jython

Thanks to a lot of work from Leo Soto during a Google Summer of Code project, Django’s codebase has been refactored to remove incompatibilities with Jython, an implementation of Python written in Java, which runs Python code on the Java Virtual Machine. Django is now compatible with the forthcoming Jython 2.5 release.

Lihat Menjalankan Django pada Jyton.

Generic relations in forms and admin

Classes are now included in django.contrib.contenttypes which can be used to support generic relations in both the admin interface and in end-user forms. See the documentation for generic relations for details.

Perbedaan INSERT/UPDATE

Although Django’s default behavior of having a model’s save() method automatically determine whether to perform an INSERT or an UPDATE at the SQL level is suitable for the majority of cases, there are occasional situations where forcing one or the other is useful. As a result, models can now support an additional parameter to save() which can force a specific operation.

Lihat Forcing an INSERT or UPDATE untuk rincian.

Pisah CacheMiddleware

Django’s CacheMiddleware has been split into three classes: CacheMiddleware itself still exists and retains all of its previous functionality, but it is now built from two separate middleware classes which handle the two parts of caching (inserting into and reading from the cache) separately, offering additional flexibility for situations where combining these functions into a single middleware posed problems.

Full details, including updated notes on appropriate use, are in the caching documentation.

Refactored django.contrib.comments

As part of a Google Summer of Code project, Thejaswi Puthraya carried out a major rewrite and refactoring of Django’s bundled comment system, greatly increasing its flexibility and customizability.

Pemindahan fitur usang

A number of features and methods which had previously been marked as deprecated, and which were scheduled for removal prior to the 1.0 release, are no longer present in Django. These include imports of the form library from django.newforms (now located simply at django.forms), the form_for_model and form_for_instance helper functions (which have been replaced by ModelForm) and a number of deprecated features which were replaced by the dispatcher, file-uploading and file-storage refactorings introduced in the Django 1.0 alpha releases.

Masalah yang diketahui

We’ve done our best to make Django 1.0 as solid as possible, but unfortunately there are a couple of issues that we know about in the release.

Multi-table model inheritance with to_field

If you’re using multiple table model inheritance, be aware of this caveat: child models using a custom parent_link and to_field will cause database integrity errors. A set of models like the following are not valid:

class Parent(models.Model):
    name = models.CharField(max_length=10)
    other_value = models.IntegerField(unique=True)

class Child(Parent):
    father = models.OneToOneField(Parent, primary_key=True, to_field="other_value", parent_link=True)
    value = models.IntegerField()

Kesalahan ini akan diperbaiki di terbitan selanjutnya dari Django.

Peringatan dengan dukungan basisdata tertentu

Django attempts to support as many features as possible on all database backends. However, not all database backends are alike, and in particular many of the supported database differ greatly from version to version. It’s a good idea to checkout our notes on supported database: