---
title: "Aplikasi"
version: 1.9
locale: id
source: https://docs.djangoproject.com/id/1.9/ref/applications/
canonical: https://djangodocs.dev/id/1.9/ref/applications/
---
# Aplikasi

DJango mengandung sebuah registrar dari aplikasi terpasang yang menyimpan konfigurasi dan menyediakan introspeksi. Dia juga merawat daftar dari ketersediaan [models](/id/1.9/topics/db/models/).

Registrar ini hanya disebut [`apps`](#django.apps.apps) dan tersedia di [`django.apps`](#module-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 sebauh 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 Pyton yang menyediakan beberapa kumpulan fitur. Aplikasi [mungkin dapat digunakna kembali](/id/1.9/intro/reusable-apps/) di beragam proyek.

Aplikasi menyertakan beberapa perpaduan dari model, tampilan, etiket cetakan, berkas statis, URL, middleware, dll. Mereka umumnya diikat kedalam proyek dengan pengaturan [`INSTALLED_APPS`](/id/1.9/ref/settings/#std-setting-INSTALLED_APPS) dan dengan mekanisme lain seperti URLconf, pengaturan [`MIDDLEWARE_CLASSES`](/id/1.9/ref/settings/#std-setting-MIDDLEWARE_CLASSES), atau cetakan turunan.

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`](#django.apps.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`](/id/1.9/ref/settings/#std-setting-INSTALLED_APPS)).

## Konfigurasi aplikasi

Untuk mengkonfigurasi sebuah aplikasi, subkelas [`AppConfig`](#django.apps.AppConfig) dan menaruh jalur titik ke subkelas tersebut dalam [`INSTALLED_APPS`](/id/1.9/ref/settings/#std-setting-INSTALLED_APPS).

Ketika [`INSTALLED_APPS`](/id/1.9/ref/settings/#std-setting-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`](#django.apps.AppConfig) untuk aplikasi tersebut.

Jika tidak ada `default_app_config`, Django menggunakan kelas dasar [`AppConfig`](#django.apps.AppConfig).

`default_app_config` mengizinkan aplikasi yang mendahului Django 1.7 seperti django.contrib.admin\` untuk memasukkan ke fitur [`AppConfig`](#django.apps.AppConfig) tanpa membutuhkan pengguna memperbaharui [`INSTALLED_APPS`](/id/1.9/ref/settings/#std-setting-INSTALLED_APPS) mereka.

Aplikasi baru harus menghindari `default_app_config`. Sebagai gantinya mereka harus butuh jalur bertitik ke subkelas [`AppConfig`](#django.apps.AppConfig) sesuai untuk di konfigurasi secara eksplisit di [`INSTALLED_APPS`](/id/1.9/ref/settings/#std-setting-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`](#django.apps.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`](/id/1.9/ref/settings/#std-setting-INSTALLED_APPS) hanya mengandung `'rock_n_roll'`. Ini mengizinkan anda untuk membuat penggunaan dari fitur [`AppConfig`](#django.apps.AppConfig) tanpa membutuhkan pengguna anda untuk memperbaharui pengaturan [`INSTALLED_APPS`](/id/1.9/ref/settings/#std-setting-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`](/id/1.9/ref/settings/#std-setting-INSTALLED_APPS) sebagai digambarkan selanjutnya.

Tentu saja, anda dapa juga mengatakan pengguna anda untuk menaruh `'rock_n_roll.apps.RockNRollConfig'` di pengaturan [`INSTALLED_APPS`](/id/1.9/ref/settings/#std-setting-INSTALLED_APPS) mereka. Anda dapat bahkan menyediakan beberapa perbedaan subkelas [`AppConfig`](#django.apps.AppConfig) dengan kebiasaan berbeda dan mengizinkan pengguna anda untuk memilih sati melalui pengaturan [`INSTALLED_APPS`](/id/1.9/ref/settings/#std-setting-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`](#django.apps.AppConfig.name) utnuk Django untuk menentukan aplikasi mana konfigurasi ini berlaku. Anda dapat menentukan atribut apapun didokumentasikan di acuan API  [`AppConfig`](#django.apps.AppConfig).

> **Note**
>
> Jika kode mengimpor registry 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 registry 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`

Konfigurasi aplikasi obyek menyimpan metadata untuk sebuah aplikasi. Beberapa atribut dapat dikonfigurasikan di subkelas [`AppConfig`](#django.apps.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`](#django.apps.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 sebuah pengindahan eksplisit sebagai atribut kelas di subkelas [`AppConfig`](#django.apps.AppConfig) anda. Dalam beberapa situasi ini dibutuhkan; sebgai contoh jika paket aplikasi adalah [namespace package](#namespace-package) dengan banyak jalur.

### Atribut hanya-baca

#### `AppConfig.module`

Modul akar untuk aplikasi, sebagai contoh `<module 'django.contrib.admin' from 'django/contrib/admin/__init__.pyc'>`.

#### `AppConfig.models_module`

Modul mengandung model, sebagai contoh `<module 'django.contrib.admin.models' from 'django/contrib/admin/models.pyc'>`.

Itu mungkin `None` jika aplikasi tidak mengandung sebuah modul `models`. Catat bahwa basisdata terkait sinyal seperti [`pre_migrate`](/id/1.9/ref/signals/#django.db.models.signals.pre_migrate) dan [`post_migrate`](/id/1.9/ref/signals/#django.db.models.signals.post_migrate) hanya dimunculkan untuk aplikasi yang mempunyai sebuah modul `models`

### Cara

#### `AppConfig.get_models()`

Mengembalikan kelas [`Model`](/id/1.9/ref/models/instances/#django.db.models.Model) berulang untuk aplikasi ini.

#### `AppConfig.get_model(model_name)`

mengembalikan [`Model`](/id/1.9/ref/models/instances/#django.db.models.Model) dengan `model_name` diberikan. Menimbulkan [`LookupError`](https://docs.python.org/3/library/exceptions.html#LookupError) jika tidak ada model seperti itu di aplikasi ini. `model_name` adalah tidak sensitif.

#### `AppConfig.ready()`

Subkelas dapat mengesampingkan cara ini untuk melakukan tugas inisialisasi seperti mendaftarkan sinyal. Dia dipanggil segera ketika registrar dikumpulkan penuh.

Anda tidak dapat mengimpor model dalam modul yang menentukan kelas konfigurasi aplikasi, tetapi anda dapat menggunakan [`get_model()`](#django.apps.AppConfig.get_model) untuk mengakses kelas model berdasarkan nama, seperti ini:

```
def ready(self):
    MyModel = self.get_model('MyModel')
```

> **Warning**
>
> Meskipun anda dapat mengakses kelas-kelas model seperti yang digambarkan dibawah, hindari berinteraksi dengan basisdata dalam penerapan [`ready()`](#django.apps.AppConfig.ready) anda. Ini termasuk cara model yang menjalankan permintaan ([`save()`](/id/1.9/ref/models/instances/#django.db.models.Model.save), [`delete()`](/id/1.9/ref/models/instances/#django.db.models.Model.delete), manager methods etc.), dan juga permintaan SQL mentah melalui cara `django.db.connection`. Your [`ready()`](#django.apps.AppConfig.ready) akan jalan selama permulaan dari stiap perintah pengelolaan. Sebagai contoh, meskipun konfigurasi basis data percobaan terpisah dari pengaturan produksi, `manage.py test` masih dapat menjalankan beberapa permintaan terhadap basisdata **produksi** anda!

> **Note**
>
> 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-kelas `AppConfig` anda utnuk mencegah menjalankan kembali kode yang seharusnya dijalankan tepatnya satu waktu.

### Paket namespace sebagai aplikasi (Python 3.3+)

Phyton versi 3.3 dan kemudian mendukung paket Phyton tanpa berkas `__init__.py`. Paket ini dikenal sebagai "paket namespace" dan mungkin tersebar terhadap banyak direktori pada tempat berbeda di `sys.path` (lihat [**PEP 420**](https://peps.python.org/pep-0420/)).

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:

1. Paket namespace sebenarnya mempunyai hanya tempat tunggal (yaitu tidak tersebar terhadap lebih dari satu direktori.)
2. Kelas [`AppConfig`](#django.apps.AppConfig) digunakan untuk mengkonfigurasikan aplikasi yang mempunyai atribut kelas [`path`](#django.apps.AppConfig.path), 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`](/id/1.9/ref/exceptions/#django.core.exceptions.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 cara [`AppConfig.ready()`](#django.apps.AppConfig.ready) dipanggil.

#### `apps.get_app_configs()`

Mengembalikan instance berulang dari  [`AppConfig`](#django.apps.AppConfig).

#### `apps.get_app_config(app_label)`

Mengembalikan sebuah [`AppConfig`](#django.apps.AppConfig) untuk aplikasi dengan `app_label`. yang diberikan. Memunculkan [`LookupError`](https://docs.python.org/3/library/exceptions.html#LookupError) jika tidak ada aplikasi.

#### `apps.is_installed(app_name)`

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

Mengembalikan [`Model`](/id/1.9/ref/models/instances/#django.db.models.Model) dengan `app_label` yang diberikan dan `model_name`. Sebagai sebuah jalan pintas, cara ini juga menerima argumen tunggal dalam bentuk `app_label.model_name`. `model_name` kasus- tidak peka.

Memunculkan [`LookupError`](https://docs.python.org/3/library/exceptions.html#LookupError) jika tidak seperti aplikasi atau model ada. Memunculkan [`ValueError`](https://docs.python.org/3/library/exceptions.html#ValueError) ketika dipanggil dengan argumen tunggal yang tidak mengandung satu titik.

## Inisialisasi pengolahan

### Bagaimana aplikasi dimuat

Ketika Django mulai, [`django.setup()`](#django.setup) bertanggung jawab untuk mengumpulkan registrar aplikasi.

#### `setup()`

Konfigurasi Django oleh:

- Memuat pengaturan.
- Mengatur pencatatan.
- 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`](/id/1.9/ref/settings/#std-setting-INSTALLED_APPS).

1. Django pertama mengimpor setiap barang di [`INSTALLED_APPS`](/id/1.9/ref/settings/#std-setting-INSTALLED_APPS).

   Jika itu sebuah kelas konfigurasi aplikasi, Django impor paket akar dari aplikasi, ditentukan oleh atribut [`name`](#django.apps.AppConfig.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`](/id/1.9/ref/settings/#std-setting-INSTALLED_APPS), sangat dianjurkan tidak mengimpor model apapun pada tingkatan ini.

   Sekali tingkatan ini lengkap, API yang menjalankan konfigurasi aplikasi seperti [`get_app_config()`](#django.apps.apps.get_app_config) menjadi tidak berguna.
2. Kemudian Django berusaha mengimpor submodul `model` dari setiap aplikasi, jika memang ada.

   Anda harus menentukan atau mengimpor semua model di aplikasi `models.py` anda atau `models/__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()`](#django.apps.apps.get_model) menjadi dapat digunakan.
3. Akhirnya Django menjalankan cara [`ready()`](#django.apps.AppConfig.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 modul model membangkitkan kode yang bergantung pada registrar aplikasi.

  Sebagai contoh, [`ugettext()`](/id/1.9/ref/utils/#django.utils.translation.ugettext) menggunakan registrar aplikasi untuk mencari katalog terjemahan di aplikasi. Untuk menterjemah pada waktu impor, anda butuh [`ugettext_lazy()`](/id/1.9/ref/utils/#django.utils.translation.ugettext_lazy). (menggunakan [`ugettext()`](/id/1.9/ref/utils/#django.utils.translation.ugettext) akan menjadi 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.

  Pelaku umum lainnya adalah [`django.contrib.auth.get_user_model()`](/id/1.9/topics/auth/customizing/#django.contrib.auth.get_user_model). Menggunakan pengaturan [`AUTH_USER_MODEL`](/id/1.9/ref/settings/#std-setting-AUTH_USER_MODEL) untuk mengacu model User pada waktu impor.

  Pengecualian ini juga terjadi jika anda lupa memanggil [`django.setup()`](#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 dijalankan ketika anda pertama butuh hasilnya. Konsep ini dikenal sebagai "lazy evaluation".
- `django.contrib.admin` automatically performs autodiscovery of `admin`
  modules in installed applications. To prevent it, change your
  [`INSTALLED_APPS`](/id/1.9/ref/settings/#std-setting-INSTALLED_APPS) to contain
  `'django.contrib.admin.apps.SimpleAdminConfig'` instead of
  `'django.contrib.admin'`.