Dokumen ini menjelaskan beberapa dari filosofi dasar pengembang Django yang telah digunakan dalam membuat kerangka. Tujuannya adalah menjelaskan yang lampau dan memandu masa akan datang.
\nSasaran dasar tumpukan Django adalah loose coupling and tight cohesion. Bermacam lapisan dari kerangka jangan "mengetahui" tentang satu sama lain meskipun sangat butuh.
\nSebagai contoh, sistem cetakan tidak mengetahui tentang permintaan jaringan, lapisan basisdata tidak mengetahui tentang data ditampilkan dan sistem tampilan tidak peduli sistem cetakan mana yang digunakan seorang pemrogram.
\nMeskipun Django datang dengan tumpukan penuh keyakinan, potongan dari tumpukan adalah berdiri sendiri dari lainnya sedapat mungkin.
\nAplikasi Django harus menggunakan sedikit kode sebisa mungkin; mereka kekurangan boilerplate. Django harus mengambil keuntungan penuh dari kemampuan dinamis Phyton, seperti interospeksi.
\nTitik dari kerangka kerja jaringan dalam abad 21 adalah membuat aspek membosankan dari pengembangan jaringan cepat. Django harus mengizinkan pengembangan jaringan cepat yang luar biasa.
\nSetiap konsep berbeda dan/atau potongan data harus berada dalam satu, dan hanya satu, tempat. Pengulangan adalah buruk. Normalisasi adalah bagus.
\nKerangka, dalam alasan, harus menyimpulkan sebanyak mungkin dari sekecil mungkin.
\n\nIni adalah prinsip inti Phyton terdaftar di PEP 20, dan itu berarti Django tidak harus melakukan banyak "magic." Magic jangan terjadi meskipun terdapat alasan sangat bagus. magic adalah berharga menggunakan jika dia membuat kenyamanan besar tidak terjangkau di jalan lain, dan dia tidak diterapkan di jalan yang membingungkan pengembang yang mencoba mempelajari bagaimana menggunakan fitur.
\nKerangka harus konsisten pada semua tingkatan. Konsistensi berlaku ke semua dari tingkatan-rendah (menggunakan gaya pengkodean Phyton) sampai tingkatan-tinggi ("pengalaman" menggunakan Django).
\nBidang jangan dianggap kebiasaan tertentu berdasarkan hanya pada nama bidang. Ini membutuhkan terlalu banyak pengetahuan dari sistem dan cenderung menjadi kesalahan. Malahan, kebiasaan harus berdasarkan pada argumen kata kunci dan, di beberapa kasus, pada jenis bidang.
\nModel harus merangkum setiap aspek dari sebuah "obyek," mengikuti pola rancangan Active Record Fowler.
\nIni mengapa kedua data dibawakan oleh model dan informasi mengenai dia (dia nama yang dapat dibaca manusia, pilihan seperti pengurutan awal, dll.) ditentukan di kelas model; semua informasi yang dibutuhkan untuk memahami model yang diberikan harus disimpan di dalam model.
\nSasaran inti dari API basisdata adalah:
\nDia harus menjalankan pernyataan SQL sedikit waktu mungkin, dan dia harus mengoptimalkan pernyataan secara internal.
\nIni adalah mengapa pengembang butuh memanggil save() secara eksplisit, dari pada kerangka menyimpan hal-hal dibelakang layar secara sembunyi.
This is also why the FETCH_PEERS fetch mode\nexists. It's an optional performance booster for the common case of selecting\nrelated objects for every peer in a QuerySet.
API basisdata harus mengijinkan kaya, pernyataan ungkapan sebagai sintaks kecil sebisa mungkin. Itu harus tidak bergantung pada mengimpor modul lain atau obyek pembantu.
\nPenggabungan harus dilakukan otomatis, dibelakang layar, ketika dibutuhkan.
\nSetiap obyek harus mampu mengakses setiap obyek terhubung, sistem lebar. Akses ini harus bekerja dikedua cara.
\nAPI basisdata harus menyadari jalan pintasnya tetapi tidak perlu akhir-semua-akan-semua. Kerangka harus membuatnya mudah untuk menulis SQL penyesuaian -- seluruh pernyataan, atau hanya klausa WHERE penyesuaian sebagai parameter penyesuaian ke pemanggilan API.
URL di aplikasi Django tidak boleh bergandengan ke kode Phyton pokok. Mengikat URL ke nama fungsi Phyton adalah Hal Buruk Dan Jelek.
\nBersama baris ini, sistem URL Django harus mengizinkan URL untuk aplikasi sama menjadi berbeda di konteks berbeda. Sebagai contoh, satu situs mungkin menaruh cerita pada /stories/, dimana lainnya mungkin menggunakan /news/.
URL harus sefleksibel mungkin. Apapun rancangan URL yang dipikirkan harus diizinkan.
\nKerangka harus membuatnya semudah (atau bahkan lebih mudah) untuk pengembang merancang URL cantik daripada yang jelek.
\nBerkas ekstensi dalam URL halaman-jaringan harus dihindari.
\nKoma gaya Vignette dalam URL pantas hukuman berat.
\nSecara teknis, foo.com/bar dan foo.com/bar/ adalah dua URL berbeda, dan robot mesin-pencari (dan beberapa alat analisa-lalu-lintas) akan memperlakukan mereka sebagai halaman terpisah. Django harus membuat sebuah usaha untuk "menormalkan" URL sehingga robot mesin-pencari itu tidak bingung.
Ini adalah alasan dibelakang pengaturan APPEND_SLASH.
Kami melihat sistem cetakan sebagai alat yang mengendalikan penyajian dan penyajian-logika terhubung -- dan itu dia. Sistem cetakan jangan mendukung fungsi yang pergi melebihi sasaran dasar ini.
\nKebanyakan dari situs jaringan dinamis menggunakan beberapa urutan rancangan situs lebar umum -- kepala umum, kaku, batang navigasi, dll. Sistem cetakan Django harus membuatnya mudah untuk menyimpan unsur tersebut dalam tempat tunggal, menghilangkan kode ganda.
\nIni adalah filosoi dibelakang warisan cetakan.
\nSistem cetakan jangan dirancang sehingga dia hanya mengeluarkan HTML. Dia harus sama bagus pada membangkitkan bentuk berbasis-teks, atau hanya teks polos.
\nMenggunakan mesin XML untuk mengurai cetakan memperkenalkan seluruh dunia baru dari kesalahan manusia dalam menyunting cetakan -- dan membuat sebuah tingkatan tidak diterima dari kelebihan pengolahan cetakan.
\nSistem cetakan jangan dirancang sehingga cetakan perlu ditampilkan di penyunting WYSIWYG seperti Dreamweaver. Yang terlalu parah pembatasan dan tidak akan mengizinkan sintaks menjadi sebaik itu. Django mengharapkan cetakan penulis nyaman menyunting HTML secara langsung.
\nSistem cetakan jangan melakukan hal magic dengan spasi. Jika cetakan menyertakan spasi, sistem harus memperlakukan ruang kosong seperti dia memperlakukan teks -- tampilkan dia. Spasi apapun yang bukan berada di etiket cetakan harus ditampilkan.
\nSasarannya bukan untuk membuat bahasa pemrograman. Sasarannya adalah menawarkan cukup fungsi mirip-pemrograman, seperti percabangan dan perulangan, yang pada dasarnya untuk membuat keputusan penyajian-terhubung. Django Template Language (DTL) bertujuan untuk menghindari logika lanjut.
\nSistem cetakan, diluar kotak, harus melarang masuknya kode berbahaya -- seperti perintah yang menghapus rekaman basisdata.
\nIni adalah alasan lain sistem cetakan tidak mengizinkan sewenang-wenang kode Pyton.
\nSistem cetakan harus mengenali penulis cetakan lanjut mungkin ingin memperpanjang teknologinya.
\nIni adalah filosofi dibelakang etiket cetakan penyesuaian dan saringan.
\nMenulis tampilan harus semudah menulis fungsi Phyton. Pengembang jangan meng instantiate sebuah kelas ketika fungsi akan melakukannya.
\nTampilan harus mempunyai akses untuk meminta obyek -- sebuah obyek yang menyimpan metadata tentang permintaan saat ini. Obyek harus melewati secara langsung ke fungsi tampilan, dari pada fungsi tampilan mempunyai akses permintaan data dari variabel global. Ini membuat cahaya, bersih dan mudah untuk dicoba tampilan dengan melewatkan permintaan "tiruan" obyek.
\nSebuah tampilan jangan perduli tentang sistem cetakan mana pengembang gunakan -- atau bahkan apakah sistem cetakan digunakan sama sekali.
\nGET dan POST berbeda; pengembang harus secara eksplisit menggunakan satu atau lainnya. Kerangka harus membuatnya mudah untuk membedakan diantara data GET dan POST.
\nSasaran inti dari cache framework Django adalah:
\nA cache should be as fast as possible. Hence, all framework code surrounding\nthe cache backend should be kept to the absolute minimum, especially for\nget() operations.
API penyimpanan harus menyediakan antarmuka tetap terhadap backend penyimpanan berbeda.
\nAPI penyimpanan harus dapat diperpanjang pada tingkatan aplikasi berdasarkan pada kebutuhan pengembang (sebagai contoh, lihat Perubahan kunci cache).
\n