Aplikasi¶
Django mengandung sebuah registrar dari aplikasi terpasang yang menyimpan konfigurasi dan menyediakan introspeksi. Dia juga merawat daftar dari ketersediaan models.
Registrar ini hanya disebut apps
dan tersedia di django.apps
:
>>> from django.apps import apps
>>> apps.get_app_config('admin').verbose_name
'Admin'
Proyek dan aplikasi¶
Istilah proyek menggambarkan sebuah aplikasi Django. Proyek paket Python ditentukan terutama dengan mengatur modul, tetapi biasanya mengandung hal lain. Sebagai contoh, ketika anda menjalankan django-admin startproject mysite
anda akan mendapatkan sebuah direktori proyek mysite
yang mengandung sebuah paket Python mysite
dengan settings.py
, urls.py
, dan wsgi.py
. Paket proyek sering diperluas untuk disertakan untuk menyertakan hal-hal seperti perbaikan, CSS, dan cetakan yang tidak diikat ke aplikasi tertentu.
Sebuah direktori akar proyek (satu yang mengandung manage.py
) biasanya mengandung semua aplikasi proyek yang tidak dipasang secara terpisah.
Istilah aplikasi menggambarkan paket Python yang menyediakan beberapa kumpulan fitur. Aplikasi may be reused di beragam proyek.
Aplikasi menyertakan beberapa kombinasi model, tampilan, cetakan, etiket cetakan, berkas tetap, URL, middleware, dll. Mereka umumnya diikat kedalam proyek dengan pengaturan INSTALLED_APPS
dan secara pilihan dengan mekanisme lain seperti URLconf, pengaturan MIDDLEWARE
, atau warisan cetakan.
Sangat penting untuk dimengerti bahwa aplikasi Django hanyalah kumpulan kode yang saling mempengaruhi dengan beragam bagian dari kerangka. Tidak ada sesuatu seperti obyek Aplikasi
. Bagaimanapun, terdapat sedikit tempat dimana Django butuh saling mempengaruhi dengan aplikasi terpasang, terutama untuk konfigurasi dan juga untuk introspeksi. Itu mengapa registrar aplikasi merawat metadata dalam sebuah instance AppConfig
untuk setiap aplikasi terpasang.
Tidak ada batasan bahwa sebuah paket proyek tidak dapat dianggap sebuah aplikasi dan mempunyai model, dll. (yang akan butuh menambahkannya ke INSTALLED_APPS
).
Konfigurasi aplikasi¶
Untuk mengkonfigurasi sebuah aplikasi, subkelas AppConfig
dan menaruh jalur titik ke subkelas tersebut dalam INSTALLED_APPS
.
Ketika INSTALLED_APPS
sederhana mengandung jalur titik ke modul aplikasi, Django memeriksa untuk variabel default_app_config
di modul tersebut.
Jika dia ditentukan, jalur bertitik ke subkelas AppConfig
untuk aplikasi tersebut.
Jika tidak ada default_app_config
, Django menggunakan kelas dasar AppConfig
.
default_app_config
mengizinkan aplikasi yang mendahului Django 1.7 seperti django.contrib.admin` untuk memasukkan ke fitur AppConfig
tanpa membutuhkan pengguna memperbaharui INSTALLED_APPS
mereka.
Aplikasi baru harus menghindari default_app_config
. Sebagai gantinya mereka harus butuh jalur bertitik ke subkelas AppConfig
sesuai untuk di konfigurasi secara eksplisit di INSTALLED_APPS
.
Untuk pengarang aplikasi¶
Jika anda membuat sebuah aplikasi dapat dipasang dipanggil "Rock ’n’ roll", ini adalah bagaimana anda akan menyediakan sebuah nama pantas untuk admin:
# rock_n_roll/apps.py
from django.apps import AppConfig
class RockNRollConfig(AppConfig):
name = 'rock_n_roll'
verbose_name = "Rock ’n’ roll"
Anda dapat membuat aplikasi anda memuat subkelas ini AppConfig
subclass secara awal sebagai berikut:
# rock_n_roll/__init__.py
default_app_config = 'rock_n_roll.apps.RockNRollConfig'
Itu akan menyebabkan RockNRollConfig
untuk digunakan ketika INSTALLED_APPS
hanya mengandung 'rock_n_roll'
. Ini mengizinkan anda untuk membuat penggunaan dari fitur AppConfig
tanpa membutuhkan pengguna anda untuk memperbaharui pengaturan INSTALLED_APPS
mereka. Disamping ini menggunakan kasus, adalah terbaik untuk menghindari menggunakan default_app_config
dan sebagai gantinya menentukan kelas konfigurasi aplikasi di INSTALLED_APPS
sebagai digambarkan selanjutnya.
Tentu saja, anda dapa juga mengatakan pengguna anda untuk menaruh 'rock_n_roll.apps.RockNRollConfig'
di pengaturan INSTALLED_APPS
mereka. Anda dapat bahkan menyediakan beberapa perbedaan subkelas AppConfig
dengan kebiasaan berbeda dan mengizinkan pengguna anda untuk memilih sati melalui pengaturan INSTALLED_APPS
mereka.
Ketentuan yang dianjurkan adalah menaruh kelas konfigurasi di submodul dari aplikasi dipanggil apps
. Bagaimanapun, ini tidak akan dipaksakan oleh Django.
Anda harus menyertakan atribut name
untuk Django untuk menentukan aplikasi mana konfigurasi ini berlaku. Anda dapat menentukan atribut apapun didokumentasikan di acuan API AppConfig
.
Catatan
Jika kode mengimpor registrar aplikasi di __init__.py
aplikasi, nama apps
akan bentrok dengan submodul apps
. Praktik terbaik adalah memindahkan kode tersebut ke submodul dan mengimpornya. Sebuah solusi adalah mengimpor registrar dibawah nama berbeda:
from django.apps import apps as django_apps
Untuk pengguna aplikasi¶
Jika anda menggunakan "Rock ’n’ roll" dalam proyek disebut anthology
, tetapi anda ingin menampilkan "Jazz Manouche", anda dapat menyediakan konfigurasi anda sendiri:
# anthology/apps.py
from rock_n_roll.apps import RockNRollConfig
class JazzManoucheConfig(RockNRollConfig):
verbose_name = "Jazz Manouche"
# anthology/settings.py
INSTALLED_APPS = [
'anthology.apps.JazzManoucheConfig',
# ...
]
Lagi, menentukan kelas konfigurasi proyek-khusus di submodul dipanggil apps
adalah sebuah ketentuan, bukan sebuah persyaratan.
Konfigurasi aplikasi¶
-
class
AppConfig
[sumber]¶ Konfigurasi aplikasi obyek menyimpan metadata untuk sebuah aplikasi. Beberapa atribut dapat dikonfigurasikan di subkelas
AppConfig
. Lainnya disetel oleh Django dan hanya-baca.
Atribut dapat dikonfigurasi¶
-
AppConfig.
name
¶ Jalur Phyton penuh ke aplikasi, sebagai contoh
'django.contrib.admin'
.Atribut ini menentukan konfigurasi aplikasi mana yang berlaku. DIa harus disetel di semua subkelas
AppConfig
.Dia harus unik terhadap proyek Django.
-
AppConfig.
label
¶ Nama pendek untuk aplikasi, sebagai contoh
'admin'
Atribut ini mengizinkan melabel kembali sebuah aplikasi ketika dua aplikasi mempunyai label bertentangan. Awal dia ke komponen terakhir dari
name
. Dia harus penciri Python yang sah.Dia harus unik terhadap proyek Django.
-
AppConfig.
verbose_name
¶ Nama dapat dibaca manusia untuk aplikasi, sebagai contoh "Administrasi".
Atribut awal ke
label.title()
.
-
AppConfig.
path
¶ Jalur sistem berkas pada direktori aplikasi, sebagai contoh
'/usr/lib/python3.4/dist-packages/django/contrib/admin'
.Dalam banyak kasus, Django dapat otomatis mengenali dan mengatur ini, tetapi anda dapat juga menyediakan menimpa eksplisit sebagai atribut kelas di subkelas
AppConfig
anda. Dalam beberapa situasi ini diwajibkan; sebagai contoh jika paket aplikasi adalah namespace package dengan banyak jalur.
Atribut hanya-baca¶
-
AppConfig.
module
¶ modul utama/akar untuk aplikasi, misalnya "<module 'django.contrib.admin' from 'django/contrib/admin/__init__.py'>".
-
AppConfig.
models_module
¶ Modul yang berisi model, misalnya "<module 'django.contrib.admin.models' from 'django/contrib/admin/models.py'>".
Itu mungkin
None
jika aplikasi tidak mengandung sebuah modulmodels
. Catat bahwa basisdata terkait sinyal sepertipre_migrate
danpost_migrate
hanya dimunculkan untuk aplikasi yang mempunyai sebuah modulmodels
Cara¶
-
AppConfig.
get_models
()[sumber]¶ Mengembalikan kelas
Model
berulang untuk aplikasi ini.Membutuhkan aplikasi registrar untuk sepenuhnya dikumpulkan.
-
AppConfig.
get_model
(model_name, require_ready=True)[sumber]¶ Mengembalikan
Model
denganmodel_name
diberikan.model_name
adalah tidak sensitif.Memunculkan
LookupError
jika tidak ada model yang ada dalam aplikasi ini.Membutuhkan aplikasi regristrar untuk sepenuhnya dikumpulkan meskipun argumen
require_ready
disetel menjadiFalse
.require_ready
berperilaku tepat seperti dalamapps.get_model()
.New in Django 1.11:Argumen kata kunci
require_ready
telah ditambahkan.
-
AppConfig.
ready
()[sumber]¶ Subkelas dapat menimpa metode ini untuk melakukan tugas inisialisasi seperti mendaftarkan sinyal. Dia dipanggil segera ketika registrar dikumpulkan penuh.
Meskipun anda tidak dapat mengimpor pada tingkat-modul dimana kelas-kelas
AppConfig
ditentukan, anda dapat mengimporready()
, menggunakan antara pernyataanimport
atauget_model()
.Jika anda sedang mendaftarkan
model signals
, anda dapat mengacu pada pengirim berdasarkan label deretan karakter nya daripada menggunakan kelas model itu sendiri.Contoh:
from django.db.models.signals import pre_save def ready(self): # importing model classes from .models import MyModel # or... MyModel = self.get_model('MyModel') # registering signals with the model's string label pre_save.connect(receiver, sender='app_label.MyModel')
Peringatan
Meskipun anda dapat mengakses kelas-kelas model seperti yang digambarkan dibawah, hindari berinteraksi dengan basisdata dalam penerapan
ready()
anda. Ini termasuk cara model yang mengerjakan permintaan (save()
,delete()
, manager methods etc.), dan juga permintaan SQL mentah melalui caradjango.db.connection
. Yourready()
akan jalan selama permulaan dari stiap perintah pengelolaan. Sebagai contoh, meskipun konfigurasi basis data percobaan terpisah dari pengaturan produksi,manage.py test
masih dapat mengerjakan beberapa permintaan terhadap basisdata produksi anda!Catatan
Dalam pengolahan inisialisasi biasa, cara
ready
hanya dipanggil sekali oleh Django. Tetapi dalam kasus-kasus terpojok, khususnya dalam percobaan yang remeh dengan aplikasi terpasang,ready
mngkin dipanggil lebih dari sekali. Dalam kasus tersebut, antara menulis cara idempoten, atau menaruh sebuah bendera pada kelas-kelasAppConfig
anda untuk mencegah menjalankan kembali kode yang seharusnya dikerjakan tepatnya satu waktu.
Paket namespace sebagai aplikasi¶
Paket-paket Python tanpa berkas __init__.py
dikenal sebagai "namespace packages" dan mungkin tersebar di banyak direktori pada tempat berbeda di sys.path
(see PEP 420).
Aplikasi Django membutuhkan sebuah jalus sistem berkas berbasis tunggal dimana Django (tergantung pada konfigurasi) akan mencari cetakan, aset tetap, dll. Hingga, paket namespace mungkin hanya aplikasi Django jika satu dari hal berikut adalah benar:
- Paket namespace sebenarnya mempunyai hanya tempat tunggal (yaitu tidak tersebar terhadap lebih dari satu direktori.)
- Kelas
AppConfig
digunakan untuk mengkonfigurasikan aplikasi yang mempunyai atribut kelaspath
, yang merupakan jalur direktori mutlak Django akan digunakan sebagai jalur dasar tunggal untuk aplikasi.
Jika tidak satupun dari kondisi ini bertemu, Django akan memunculkan ImproperlyConfigured
.
Registrar aplikasi¶
-
apps
¶ Registrar aplikasi menyediakan API umum berikut. Cara yang tidak ada di daftar dibawah ini dianggap pribadi dan mungkin berubah tanpa pemberitahuan.
-
apps.
ready
¶ Atribut Boolean yang disetel ke
True
setelah registrar sepenuhnya dikumpulkan dan semua caraAppConfig.ready()
dipanggil.
-
apps.
get_app_config
(app_label)¶ Mengembalikan sebuah
AppConfig
untuk aplikasi denganapp_label
. yang diberikan. MemunculkanLookupError
jika tidak ada aplikasi.
-
apps.
is_installed
(app_name)¶ Memeriksa apakah aplikasi dengan nama diberikan anda di registrar.
app_name
adalah nama penuh dari aplikasi, sebagai contoh'django.contrib.admin'
.
-
apps.
get_model
(app_label, model_name, require_ready=True)¶ Mengembalikan
Model
denganapp_label
yang diberikan danmodel_name
. Sebagai sebuah jalan pintas, metode ini juga menerima argumen tunggal dalam bentukapp_label.model_name
.model_name
kasus-tidak peka.Memunculkan
LookupError
jika tidak seperti aplikasi atau model ada. MemunculkanValueError
ketika dipanggil dengan argumen tunggal yang tidak mengandung satu titik.Membutuhkan aplikasi regristrar untuk sepenuhnya dikumpulkan meskipun argumen
require_ready
disetel menjadiFalse
.Mengatur
require_ready
menjadiFalse
mengizinkan pencarian model while the app registry is being populated, khususnya selama tahap kedua dimana itu mengimpor model. Kemudianget_model()
mempunyai pengaruh sama ketika mengimpor model. Kasus penggunaan utama adalah mengkonfigurasi kelas-kelas model dengan pengaturan, sepertiAUTH_USER_MODEL
.Ketika
require_ready
adalahFalse
,get_model()
mengembalikan sebuah kelas model yang mungkin tidak sepenuhnya berfungsi (accessor balikan mungkin hilang, sebagai contoh) sampai aplikasi regristrar sepenuhnya dikumpulkan. Untuk alasan ini, itu adalah terbaik untuk membiarkanrequire_ready
ke nilai awalan dariTrue
kapanpun memungkinkan.New in Django 1.11:Argumen kata kunci
require_ready
telah ditambahkan.
Inisialisasi pengolahan¶
Bagaimana aplikasi dimuat¶
Ketika Django mulai, django.setup()
bertanggung jawab untuk mengumpulkan registrar aplikasi.
-
setup
(set_prefix=True)[sumber]¶ Konfigurasi Django oleh:
- Memuat pengaturan.
- Mengatur pencatatan.
- Jika
set_prefix
adalah True, pengaturan awalan tulisan penyelesai URL keFORCE_SCRIPT_NAME
jika ditentukan, atau jika tidak/
. - Memulai registrar aplikasi
Fungsi ini dipanggil otomatis:
- Ketika menjalankan peladen HTTP melalui dukungan WSGI Django.
- Ketika meminta perintah pengelolaan.
Dia harus dipanggil secara tersirat di kasus lain, sebagai contoh di tulisan Phyton.
Registrar aplikasi dimulai dalam tiga tingkatan, Pada setiap tingkatan, Django mengolah semua aplikasi berdasarkan dari INSTALLED_APPS
.
Django pertama mengimpor setiap barang di
INSTALLED_APPS
.Jika itu sebuah kelas konfigurasi aplikasi, Django impor paket akar dari aplikasi, ditentukan oleh atribut
name
nya. Jika itu adalah sebuah paket Python, Django membuat konfigurasi aplikasi awal.Pada tingkatan ini, kode anda jangan mengimpor model apapun!
Dengan kata lain, paket akar aplikasi anda dan modul yang menentukan kelas-kelas konfigurasi aplikasi anda jangan impor model apapun, bahkan secara tidak langsung.
Sesungguhnya, Django mengizinkan mengimpor model sekali konfigurasi aplikasi mereka dimuat. Bagaimanapun, agar menghindari kendala yang tidak perlu pada urutan
INSTALLED_APPS
, sangat dianjurkan tidak mengimpor model apapun pada tingkatan ini.Sekali tingkatan ini lengkap, API yang menjalankan konfigurasi aplikasi seperti
get_app_config()
menjadi tidak berguna.Kemudian Django berusaha mengimpor submodul
model
dari setiap aplikasi, jika memang ada.Anda harus menentukan atau mengimpor semua model di aplikasi
models.py
anda ataumodels/__init__.py
. Sebaliknya, registri aplikasi mungkin tidak dikumpulkan penuh pada titik ini, yang dapat menyebabkan ORM tidak berfungsi.Ketika tingkatan ini lengkap, API yang bekerja di model seperti
get_model()
menjadi dapat digunakan.Akhirnya Django menjalankan cara
ready()
dari setiap konfigurasi aplikasi.
Menyelesaikan masalah¶
Disini beberapa masalah umum yang mungkin muncul selama inisialisasi:
AppRegistryNotReady
: Ini terjadi ketika mengimpor sebuah konfigurasi aplikasi atau sebuah kode pemicu modul model yang bergantung di registri aplikasi.Sebagai contoh,
gettext()
menggunakan registrar aplikasi untuk mencari katalog terjemahan di aplikasi. Untuk menterjemahkan pada waktu impor, anda butuhgettext_lazy()
sebagai gantinya. (Menggunakangettext()
akan berupa sebuah kesalahan, karena terjemahan akan terjadi pada waktu impor, daripada setiap permintaan tergantung pada bahasa aktif.)Menjalankan permintaan basisdata dengan ORM pada waktu impor dalam modul model juga akan memicu pengecualian ini. ORM tidak dapat berfungsi dengan benar sampai semua model tersedia.
Pengecualian ini juga terjadi jika anda lupa memanggil
django.setup()
di tulisan berdiri sendiri.ImportError: tidak dapat impor nama ...
Ini terjadi jika urutan impor berakhir dalam perulangan.Untuk mengurangi permasalahan tersebut, anda harus mengecilkan ketergantungan diantara model anda dan melakukan sedikit pekerjaan sebisa mungkin pada waktu impor. Untuk menghindari penjalanan kode pada waktu impor, anda dapat memindahkannya dan menembolok hasilnya. Kode akan dikerjakan ketika anda pertama butuh hasilnya. Konsep ini dikenal sebagai "lazy evaluation".
django.contrib.admin
automatically performs autodiscovery ofadmin
modules in installed applications. To prevent it, change yourINSTALLED_APPS
to contain'django.contrib.admin.apps.SimpleAdminConfig'
instead of'django.contrib.admin'
.