Menulis aplikasi Django kedua anda, bagian 2

Tutorial ini dimulai dimana Tutorial 1 tinggalkan. Kami akan mengatur basisdata, membuat model pertama anda, dan mendapatkan perkenalan cepat ke situs admin dibangkitkan-otomatis Django.

Pengaturan basisdata

Sekarang, buka mysite/settings.py. Dia adalah modul Phyton biasa dengan variabel tingkat-modul mewakili pengaturan Django.

Secara awal, konfigurasi menggunakan SQLite. Jika anda barus ke basisdata, atau anda hanya tertarik dalam mencoba Django, ini adalah pilihan termudah. SQLite disertakan di Phyton, jadi anda tidak akan butuh memasang apapun untuk mendukung basisdata anda. ketika memulai proyek sebenarnya pertama anda, bagaimanapun, anda mungkin ingin menggunakan basisdata kuat seperti PostgreSQL, untuk menghindari sakit kepala pergantian-basisdata dijalan.

Jika anda berharap menggunakan basisdata lain, pasang database bindings yang sesuai dan rubah kunci berikut di barang DATABASES 'default' untuk mencocokkan pengaturan hubungan basisdata anda:

  • ENGINE – Salah satu 'django.db.backends.sqlite3', 'django.db.backends.postgresql', 'django.db.backends.mysql', atau 'django.db.backends.oracle'. Backend lainnya adalah juga tersedia.

  • NAME – Nama dari basisdata anda. Jika anda menggunakan SQLite, basisdata akan di berkaskan di komputer anda; dalam kasus itu, NAME harus jalur mutlak penuh, termasuk nama berkas, dari berkas tersebut. Nilai awal, os.path.join(BASE_DIR, 'db.sqlite3'), akan menyimpan berkas di direktori proyek anda.

Jika anda tidak menggunakan SQlite sebagai basisdata anda, pengaturan tambahan seperti USER, PASSWORD, dan HOST harus ditambahkan. Untuk lebih rinci, lihat acuan dukumentasi untuk DATABASES.

Untuk basis data selain SQLite.

Jika anda menggunakan basisdata selain SQLite, pastikan anda membuat basisdata terlebih dahulu. Lakukan dengan “CREATE_DATABASE database_name;” melalui prompt interaktif basisdata.

Juga pastikan bahwa basisdata yang disiapkan dalam mysite/settings.py memiliki izin untuk “membuat database”. Hal ini memungkinkan untuk membuat test database yang akan dibutuhkan nanti dalam tutorial.

Jika anda sedang menggunakan SQlite, anda tidak butuh membuat apapun sebelumnya - berkas basisdata akan dibuat otomatis ketika dia dibutuhkan.

Ketika anda menyunting mysite/settings.py, setel TIME_ZONE ke zona waktu anda.

Juga, catat pengaturan INSTALLED_APPS pada bagian atas berkas. Yang menahan nama dari semua aplikasi Django yang diaktifkan di instance Django. Aplikasi dapat digunakan d banyak proyek, dan anda dapat memaketkan dan menyebarkan mereka untuk digunakan oleh lainnya di proyek mereka.

Secara awal, INSTALLED_APPS mengandung aplikasi berikut, semua yang datang dengan Django:

Aplikasi ini disertakan secara awal sebagai kenyamanan untuk kasus umum.

Beberapa aplikasi ini memanfaatkan setidaknya satu tabel basisdata, meskipun, jadi kami butuh untuk membuat tabel di basisdata sebelum kami dapat menggunakannya. Untuk melakukannya, jalankan perintah berikut:

$ python manage.py migrate

Perintah migrate mencari pengaturan INSTALLED_APPS dan membuat tabel basisdata yang dibutuhkan menurut pengaturan basisdata di berkas mysite/settings.py anda dan pemindahan basisdata dibungkus dengan aplikasi (kami akan menanganinya nanti). Anda akan melihat pesan untuk setiap pindahan yang diberlakukan. Jika anda tertarik, jalankan baris-perintah klien untuk basisdata anda dan ketik \dt (PostgreSQL), SHOW TABLES; (MySQL), .schema (SQLite), atau SELECT TABLE_NAME FROM USER_TABLES; (Oracle) untuk menampilkan tabel Django yang dibuat.

Untuk minimalis

Seperti yang kami katakan diatas, aplikasi awal disertakan untuk kasus umum, tetapi tidak setiap orang membutuhkan mereka. Jika anda tidak membutuhkan sebagian atau semua dari mereka, silahkan komentari atau hapus baris yang diinginkan dari INSTALLED_APPS sebelum menjalankan migrate. Perintah migrate akan hanya menjalankan pemindahan tempat untuk aplikasi di INSTALLED_APPS.

Membuat model

Sekarang kami akan menentukan model anda – Pada dasarnya, tata letak basisdata anda, dengan metadata tambahan.

Filosofi

Sebuah model adalah tunggal, sumber tetap dari kebenaran tentang data anda. Itu mengandung bidang penting dan kebiasaan dari data anda simpan. Django mengikuti DRY Principle. Tujuan adalah menentukan model data anda di satu tempat dan otomatis mengambil hal dari itu.

Ini menyertakan pemindahan tempat - tidak seperti Ruby On Rails, sebagai contoh, pemindahan tempat seluruhnya turunan dari berkas model anda, dan pada dasarnya hanya sejarah yang Django dapat gulirkan untuk memperbaharui skema basisdata anda untuk mencocokan model anda saat ini.

Di aplikasi jejak pendapat sederhana kami, kami akan membuat dua model Question and Choice. Question mempunyai pertannyaan dan tanggal penerbitan. Choice mempunyai dua bidang: teks pilihan dan perhitungan pilihan. Setiap Choice dihubungkan dengan Question.

Konsep ini diwakili dengan kelas Phyton sederhana. Rubah berkas polls/models.py sehingga itu kelihtan seperti ini:

polls/models.py
from django.db import models


class Question(models.Model):
    question_text = models.CharField(max_length=200)
    pub_date = models.DateTimeField('date published')


class Choice(models.Model):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    choice_text = models.CharField(max_length=200)
    votes = models.IntegerField(default=0)

Kode ini langsung. Setiap model diwakili oleh kelas yang subkelas django.db.models.Model. Setiap model mempunyai angka variabel kelas, setiap yang mewakilkan bidang basisdata di model.

Setiap bidang diwakilkan oleh instance dari kelas Field class – sebagai contoh CharField untuk bidang karakter dan DateTimeField untuk tanggal waktu. Ini memberitahu Django jenis apa dari data setiap bidang yang disimpan.

Nama dari setiap instance Field (sebagai contoh question_text` or pub_date) adalah nama bidang, di bentuk mesin-bersahabat. Anda akan menggunakan nilai ini di kode Phyton, dan basisdata anda akan menggunakannya sebagai nama kolom.

Anda dapat menggunakan pilihan argumen penempatan pertama pada Field untuk merancang nama dapat dibaca-manusia. Itu digunakan di pasangan bagian mawas diri dari Django dan dia mengganda sebagai dokumentasi. Jika bidang ini tidak disediakan, Django akan menggunakan nama dapat dibaca-manusia. Di contoh ini, kami telah hanya menentukan nama dapat dibaca-manusia untuk Question.pub_date. Untuk semua bidang lain di model ini, nama dapat dibaca-mesin akan mencukupi sebagai nama dapat dibaca-manusia nya.

Beberapa kelas Field mempunyai argumen dibutuhkan. CharField, sebagai contoh, membutuhkan anda memberikannya sebuah max_length. Yang digunakan tidak hanya untuk di skema basisdata, tetapi di pengesahan, seperti yang segera kita lihat.

Sebuah Field dapa juga mempunyai beragam argumen pilihan; dalam kasus ini, kami telah menyetel nilai default dari pilih ke 0.

Akhirnya, catatan hubungan ditentukan, menggunakan ForeignKey. Yang mengatakan Django setiap Choice terhubung pada Question tunggal. Django mendukung semua hubungan basisdata umum: banyak-ke-satu, banyak-ke-banyak, dan satu-ke-satu.

Mengaktifkan model

Ada banyak informasi yang dapat disampaikan oleh beberapa baris contoh kode di atas. Dengan kode ini, Django dapat melakukan:

  • Buat skema basisdata (pernyataan CREATE TABLE) untuk aplikasi ini.

  • Buat API akses-basisdata Phyton untuk mengakses obyek Pertanyaan dan Pilihan.

Tetapi pertama kami butuh untuk memberitahu proyek kam bahwa aplikasi jejak pendapat telah terpasang.

Filosofi

Aplikasi Django dapat ditanam: Anda dapat menggunakan sebuah aplikasi dalam banyak proyek, dan anda dapat menyebarkan aplikasi, karena mereka tidak harus diikat pada pemasangan Django yang diberikan.

Sunting berkas mysite/settings.py lagi, dan rubah pengaturan INSTALLED_APPS untuk menyertakan kalimat 'polls.apps.PollsConfig'. Dia akan kelihatan seperti ini:

mysite/settings.py
INSTALLED_APPS = [
    'polls.apps.PollsConfig',
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
]

Sekarang Django tahu menyertakan aplikasi polls. Mari kita jalankan perintah lain:

$ python manage.py makemigrations polls

Anda harus melihat sesuatu yang mirip pada berikut:

Migrations for 'polls':
  0001_initial.py:
    - Create model Choice
    - Create model Question
    - Add field question to choice

Dengan menjalankan makemigrations, anda mengatakan ke Django bahwa anda telah membuat beberapa perubahan di model anda (dalam kasus ini, anda telah membuat satu baru) dan itu anda ingin perubahan disimpan sebagai migration.

Migration adalah bagaimana Django menyimpan perubahan pada model anda (dan demikian skema basisdata anda) - mereka hanya berkas di cakram. Anda dapat membaca migration untuk model baru anda jika anda suka; Dia adalah berkas polls/migrations/0001_initial.py. Jangan khawatir, anda tidak diharapkan membaca mereka setiap waktu Django membuat satu, tetapi mereka merancang untuk menjadi dapat disunting oleh manusia dalam kasus anda ingin secara manual menarik bagaimana Django merubah hal-hal.

Terdapat perintah yang akan menjalankan perpindahan tempat untuk anda dan mengelola skema basisdata anda otomatis - itu disebut migrate, dan kami akan datang ke dia sebentar lagi - tetapi pertama mari kita lihat SQL apa yang memindahkan tempat akan berjalan. Perintah sqlmigrate mengambil nama perpindahan tempat dan mengembalikan SQL mereka:

$ python manage.py sqlmigrate polls 0001

Anda harus melihat sesuatu mirip pada berikut (kami telah membentuk kembali dia untuk dapat dibaca):

BEGIN;
--
-- Create model Choice
--
CREATE TABLE "polls_choice" (
    "id" serial NOT NULL PRIMARY KEY,
    "choice_text" varchar(200) NOT NULL,
    "votes" integer NOT NULL
);
--
-- Create model Question
--
CREATE TABLE "polls_question" (
    "id" serial NOT NULL PRIMARY KEY,
    "question_text" varchar(200) NOT NULL,
    "pub_date" timestamp with time zone NOT NULL
);
--
-- Add field question to choice
--
ALTER TABLE "polls_choice" ADD COLUMN "question_id" integer NOT NULL;
ALTER TABLE "polls_choice" ALTER COLUMN "question_id" DROP DEFAULT;
CREATE INDEX "polls_choice_7aa0f6ee" ON "polls_choice" ("question_id");
ALTER TABLE "polls_choice"
  ADD CONSTRAINT "polls_choice_question_id_246c99a640fbbd72_fk_polls_question_id"
    FOREIGN KEY ("question_id")
    REFERENCES "polls_question" ("id")
    DEFERRABLE INITIALLY DEFERRED;

COMMIT;

Catatan berikut:

  • Keluaran pasti akan bermacam tergantung di basisdata anda gunakan. Contoh diatas adalah membangkitkan untuk PostgreSQL.

  • Nama tabel otomatis dibangkitkan dengan memadukan nama dari aplikasi (polls) dan nama huruf kecil dari model – question and choice. (Anda dapat mengesampingkan kebiasaan ini.)

  • Kunci utama (ID) ditambahkan otomatis. (Anda dapat mengesampingkan ini, juga.)

  • Berdasarkan kebiasaan, DJango menambahkan "_id" ke nama bidang foreign key. (Ya, anda dapat mengesampingkan ini, juga.)

  • Hubungan foreign key adalah dibuat eksplisit dengan pembatas FOREIGN KEY. Jangan khawatir tentang bagian DEFERRABLE; Itu hanya memberitahu PostgreSQL tidak untuk memaksa foreign key sampai akhir dari transaksi.

  • Dia disesuaiakan ke basisdata anda gunakan, jadi jenis bidang basisdata-khusus seperti auto_increment (MySQL), serial (PostgreSQL), atau integer primary key autoincrement (SQLite) ditangani untuk anda otomatis. Sama berlaku untuk mengutio nama bidang – sebagai contoh, gunakan kutip ganda atau kutip tunggal.

  • Perintah sqlmigrate sebenarnya tidak menjalankan pemindahan tempat di basisdata anda - dia hanya mencetaknya ke layar sehingga anda dapat melihatnya apa SQL Django pikir diharuskan. Dia sangat berguna untuk memeriksa apa Django akan lakukan jika anda mempunyai basisdata administrator yang membutuhkan tulisan SQL untuk perubahan.

Jika anda tertarik, anda dapat juga menjalankan python periksa manage.py; pemeriksaan ini untuk masalah apapun di proyek anda tanpa membuat perindahan tempat atau menyentuk basisdata.

Sekarang, jalankan migrate kembali untuk membuat tabel model tersebut di basisdata anda:

$ python manage.py migrate
Operations to perform:
  Apply all migrations: admin, contenttypes, polls, auth, sessions
Running migrations:
  Rendering model states... DONE
  Applying polls.0001_initial... OK

Perintah migrate membawa semua pemindahan tempat yang belum diberlakukan (Django melacak yang mana diberlakukan menggunakan tabel khusus di basisdata anda disebut django_migrations) dan menjalankan mereka terhadap basisdata anda - pada dasarnya, sinkronisasi perubahan anda buat ke model anda dengan skema di basisdata.

Pemindahan tempat adalah sangat kuat dan membuat anda merubah model anda lembur, ketika anda mengembangkan proyek anda, tanpa buth menghapus basisdata anda atau tabel dan membuat satu yang baru - Dia khusus dalam meningkatkan basisdata langsung, tanpa kehilangan data. Kami akan melingkupi mereka lebih dalam di bagian kemudian dari tutorial, tetapi untuk sekarang, ingat panduan tiga-langkah untuk membuat perubahan model:

Alasan bahwa terdapat perintah pemisah untuk membaut dan memberlakukan pemindahan tempat karena anda akan menyerahkan pemindahan tempat ke sistem kendali versi anda dan mengirim mereka dengan aplikasi anda; mereka tidak hanya membuat pengmebnagan lebih mudah, mereka juga dapat digunakan pleh pengembang lain dan di produksi.

Baca django-admin documentation untuk informasi penuh pada apa alat manage.py dapat lakukan.

Bermain dengan API

Sekarang, mari kita melompat ke dalam shell Phyton dan bermain dengan API bebas DJango yang diberikan ke anda. Untuk memintah shell Phyton, gunakan perintah ini:

$ python manage.py shell

Kami menggunakan ini daripada pengetikan sederhana “phyton”, karena mengatur variabel lingkungan DJANGO_SETTINGS_MODULE, yang memberikan Django jalur impor Phyton ke bekas mysite/settings.py anda.

Memotong manage.py

Jika anda lebih baik tidak menggunakan manage.py, tidak masalah. Coba atur lingkungan variabel DJANGO_SETTINGS_MODULE ke mysite.settings, mulai shell Phyton polos, dan atur Django:

>>> import django
>>> django.setup()

Jika ini muncul sebuah AttributeError, anda mungkin menggunakan versi Django yang tidak cocok tutorial versi ini. Anda ingin salah satu mengganti ke tutorial lama atau versi Django terbaru.

Anda harus menjalankan python dari direktori sama manage.py berada, atau pastikan bahwa direktori di jalur Phyton, sehingga import mysite bekerja.

Untuk informasi lebih di semua ini, lihat django-admin documentation.

Sekali anda telah di kerang, jelajahi API basisdata:

>>> from polls.models import Question, Choice   # Import the model classes we just wrote.

# No questions are in the system yet.
>>> Question.objects.all()
[]

# Create a new Question.
# Support for time zones is enabled in the default settings file, so
# Django expects a datetime with tzinfo for pub_date. Use timezone.now()
# instead of datetime.datetime.now() and it will do the right thing.
>>> from django.utils import timezone
>>> q = Question(question_text="What's new?", pub_date=timezone.now())

# Save the object into the database. You have to call save() explicitly.
>>> q.save()

# Now it has an ID. Note that this might say "1L" instead of "1", depending
# on which database you're using. That's no biggie; it just means your
# database backend prefers to return integers as Python long integer
# objects.
>>> q.id
1

# Access model field values via Python attributes.
>>> q.question_text
"What's new?"
>>> q.pub_date
datetime.datetime(2012, 2, 26, 13, 0, 0, 775217, tzinfo=<UTC>)

# Change values by changing the attributes, then calling save().
>>> q.question_text = "What's up?"
>>> q.save()

# objects.all() displays all the questions in the database.
>>> Question.objects.all()
[<Question: Question object>]

Tunggu dulu. <Question: Question object> adalah, sama sekali, perwakilan tidak membantu dari obyek ini. Mari kita perbaiki itu dengan menyunting model Question (di berkas polls/models.py) dan menambahkan cara __str__() pada kedua Question dan Choice:

polls/models.py
from django.db import models
from django.utils.encoding import python_2_unicode_compatible

@python_2_unicode_compatible  # only if you need to support Python 2
class Question(models.Model):
    # ...
    def __str__(self):
        return self.question_text

@python_2_unicode_compatible  # only if you need to support Python 2
class Choice(models.Model):
    # ...
    def __str__(self):
        return self.choice_text

Sangat penting menambahkan cara __str__() ke model anda, tidak hanya kenyamanan anda ketika berurusan dengan prompt interaktif, tetapi juga karena perwakilan obyek digunakan di seluruh admin dibangkitkan-otomatis Django.

Catat ini adalah cara Phyton biasa. Mari kita menambahkan cara penyesuaian, hanya untuk demonstrasi:

polls/models.py
import datetime

from django.db import models
from django.utils import timezone


class Question(models.Model):
    # ...
    def was_published_recently(self):
        return self.pub_date >= timezone.now() - datetime.timedelta(days=1)

Catat tambahand dari import datetime dan from django.utils import timezone, untuk mengacu standar Phyton modul datetime dan kegunaan zona-waktu-terhubung Django di django.utils.timezone, masing-masing. Jika anda belum akrab dengan penanganan zona waktu di Phyton, anda dapat mempelajari lebih di dokumen dukungan zona waktu.

Simpan perubahan ini dan mulai shell interaktif Phyton baru dengan menjalankan python manage.py shell` kembali:

>>> from polls.models import Question, Choice

# Make sure our __str__() addition worked.
>>> Question.objects.all()
[<Question: What's up?>]

# Django provides a rich database lookup API that's entirely driven by
# keyword arguments.
>>> Question.objects.filter(id=1)
[<Question: What's up?>]
>>> Question.objects.filter(question_text__startswith='What')
[<Question: What's up?>]

# Get the question that was published this year.
>>> from django.utils import timezone
>>> current_year = timezone.now().year
>>> Question.objects.get(pub_date__year=current_year)
<Question: What's up?>

# Request an ID that doesn't exist, this will raise an exception.
>>> Question.objects.get(id=2)
Traceback (most recent call last):
    ...
DoesNotExist: Question matching query does not exist.

# Lookup by a primary key is the most common case, so Django provides a
# shortcut for primary-key exact lookups.
# The following is identical to Question.objects.get(id=1).
>>> Question.objects.get(pk=1)
<Question: What's up?>

# Make sure our custom method worked.
>>> q = Question.objects.get(pk=1)
>>> q.was_published_recently()
True

# Give the Question a couple of Choices. The create call constructs a new
# Choice object, does the INSERT statement, adds the choice to the set
# of available choices and returns the new Choice object. Django creates
# a set to hold the "other side" of a ForeignKey relation
# (e.g. a question's choice) which can be accessed via the API.
>>> q = Question.objects.get(pk=1)

# Display any choices from the related object set -- none so far.
>>> q.choice_set.all()
[]

# Create three choices.
>>> q.choice_set.create(choice_text='Not much', votes=0)
<Choice: Not much>
>>> q.choice_set.create(choice_text='The sky', votes=0)
<Choice: The sky>
>>> c = q.choice_set.create(choice_text='Just hacking again', votes=0)

# Choice objects have API access to their related Question objects.
>>> c.question
<Question: What's up?>

# And vice versa: Question objects get access to Choice objects.
>>> q.choice_set.all()
[<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]
>>> q.choice_set.count()
3

# The API automatically follows relationships as far as you need.
# Use double underscores to separate relationships.
# This works as many levels deep as you want; there's no limit.
# Find all Choices for any question whose pub_date is in this year
# (reusing the 'current_year' variable we created above).
>>> Choice.objects.filter(question__pub_date__year=current_year)
[<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]

# Let's delete one of the choices. Use delete() for that.
>>> c = q.choice_set.filter(choice_text__startswith='Just hacking')
>>> c.delete()

Untuk informasi lebih di kaitan model, lihat mengakses objek terkait. Untuk lebih bagaimana menggunakan garis bawah ganda untuk melakukan bidang lookup melalui API, lihat Bidang lookup. Untuk rincian penuh di basisdata API, lihat Acuan API basisdata kami.

Memperkenalkan Admin Django

Filosofi

Membangkitkan situs admin untuk staf atau klien anda untuk menambah, merubah, dan menghapus isi adalah pekerjaan membosankan yang tidak membutuhkan banyak kreatifitas. Untuk alasan itu, Django sepenuhnya otomatisasi pembuatan antarmuka admin untuk model.

Django ditulis di lingkungan ruang berita, dengan pemisahan jelas antara situs “penerbit umum” dan “umum”. Pengelola situs menggunakan sistem untuk menambahkan cerita berita, acara, skor olahraga, dll. dan isi itu ditampilkan di situs umum. DJango mengatasi masalah dari pembuatan antarmuka terpadu untuk administrator situs untuk menyunting isi.

Admin tidak diperuntukkan untuk digunakan oleh pengunjung situs. Itu untuk pengelola situs.

Membuat pengguna admin

Pertama kami akan butuh membuat pengguna yang dapat masuk ke situs admin. Jalankan perintah berikut:

$ python manage.py createsuperuser

Masukkan nama pengguna anda inginkan dan tekan enter.

Username: admin

Anda akan diarahkan ke alamat email yang anda inginkan:

Email address: admin@example.com

Langkah akhir adalah memasukkan sandi anda. Anda akan diminta memasukkan sandi anda dua kali, kedua kali sebagai penegasan dari yang pertama.

Password: **********
Password (again): *********
Superuser created successfully.

Nyalakan peladen pengembangan

Situs Admin Django diaktifkan secara awal. Mari kita nyalakan peladen pengembangan dan jelajahi dia.

Jika peladen tidak berjalan nyalakan seperti biasa:

$ python manage.py runserver

Sekarang, buka perambah Jaringan dan pergi ke “/admin/” di lokal admin - sebagai contoh, http://127.0.0.1:8000/admin/. Anda harus melihat layar masih admin:

Django admin login screen

Sejak translation dihidupkan secara awal, layar masuk mungkin menampilkan bahasa anda sendiri, tergantung pada pengaturan perambah anda dan jika Django mempunyai terjemahan untuk bahasa ini.

Masuk situs admin

Sekarang, coba masuk dengan akun superuser anda telah buat di langkah sebelumnya. Anda seharusnya melihat halaman index admin Django:

Django admin index page

Anda seharusnya melihat beberapa jenis isi dapat disunting: kelompok dan pengguna. Mereka disediakan oleh django.contrib.auth, kerangka pembuktian keaslian dikirim oleh Django.

Buat aplikasi jejak pendapat dapat di rubah di admin

Tetapi dimana aplikasi jejak pendapat kami? DIa tidak ditampilkan di halaman index admin.

Hanya satu hal untuk dilakukan: kami butuh memberitahu admin bahwa obyek Question mempunyai antarmuka admin. Untuk melakukannya, buka berkas polls/admin.py, dan sunting dia seperti ini:

polls/admin.py
from django.contrib import admin

from .models import Question

admin.site.register(Question)

Jelajahi fungsi admin bebas

Sekarang kita telah mendaftarkan Question, Django mengetahui bahwa itu harus ditampilkan di halaman index admin:

Django admin index page, now with polls displayed

Klik Question. Sekarang anda berada di halaman “change list” untuk pertanyaan. Halaman ini menampilkan semua pertanyaan di basisdata dan membiarkan anda memilih satu untuk merubahnya. Ada pertanyaan “Ada apa? kami buat sebelumnya:

Polls change list page

Klik pertanyaan “Ada apa?” untuk menyuntingnya:

Editing form for question object

Hal-hal untuk dicatat disini:

  • Formulir otomatis dibangkitkan dari model Question.

  • Jenis bidang model berbeda ((DateTimeField, CharField) berhubungan ke widget masukan HTML sesuai. Setiap jenis dari bidang mengetahui bagaimana menampilkan diri sendiri di admin Django.

  • Setiap DateTimeField mendapatkan jalan pintas Javascript bebas. Tanggal mendapatkan jalan pintas “Hari ini” dan popup kalender, dan waktu mendapatkan jalan pintas “Sekarang” dan popup nyaman yang menampilkan waktu dimasukkan umum.

Bagian bawah halaman memberikan anda pasangan pilihan:

  • Simpan – Simpan perubahan dan kembalikan halaman daftar-rubah untuk jenis ini dari obyek.

  • Simpan dan lanjutkan menyunting – Simpan perubahan dan muat kembali halaman admin untuk obyek ini.

  • Simpan dan tambah lain – Simpan perubahan dan muat baru, formulir kosong untuk jenis ini dari obyek.

  • Hapus – Tampilkan halaman penegasan hapus.

Jika nilai “Tanggal diterbitkan” tidak cocok waktu ketika anda membuat pertanyaan di Tutorial 1, itu kemungkinan berarti anda lupa untuk mengatur nilai benar untuk pengaturan TIME_ZONE. Rubah itu, muat kembali halaman dan periksa bahwa nilai benar muncul.

RUbah “Tanggal diterbitkan” dengan mengklik jalan pintas “Hari ini” dan “Sekarang”. Lalu klik “Simpan dan lanjut menyunting”. Lalu klik “Sejarah” di kanan atas. Anda akan melihat halaman menampilkan semua perubahan yang dibuat pada obyek ini melalui admin DJango, dengan stempel waktu dan nama pengguna dari orang yang membuat perubahan:

History page for question object

Ketika anda sudah nyaman dengan API model dan telah mengakrabkan diri anda dengan situs admin, baca part 3 of this tutorial untuk mempelajari tentang bagaimana menambahkan tampilan lebih ke aplikasi jejak pendapat kami.

Back to Top