|
Bizga response qaytarilganda browserga keladigan ma’lumot HTML, CSS va JavaScript fayllari ko’rinishida keladi(F12 ni bosib ko’ring). Bu ma’lumotlar tarkibi shartli ravishda ikki xil bo’ladi:
Tayyor shablon(qolip) va o’zgarib turadigan ma’lumotlar. Masalan, youtubeda alohida 2 ta oynada 2 xil video ochib ko’ring. E’tibor bering, sahifa dizayni, pageda qismlarning joylashgan joyi, rangi, Tepadagi “Youtube” yozuvi bir xil. Bu template(qolip) deyiladi. Lekin, ikkita pageda video, video nomi, tavsiya qilingan videolar va h.k har xil. Bu o’zgarib turadigan ma’lumotlar.
Har bir ma’lumot uchun alohida HTML kod yoza olmaymiz. Shunchaki, qolib yozib olamiz va kerakli ma’lumotlarni bu qolipdagi kerakli joylarga “yopishtirib” chiqamiz. Bu jarayon rendering deyiladi.
Tepada view bizga response qaytarishini bilib oldik. Ana shu response(aniqrog’i HTTP response) esa kerakli ma’lumotlarni tayyor templatege render qilib, keyin yuboriladi.
App
Loyiha kattalashgan sari uni alohida qismlarga ajratib, boshqarishga oson(managable) qilishga ehtiyoj tug’iladi. Bunda har bir qismning aniq vazifasi bo’lishi kerak.
Bu vazifani djangoda app’lar bajaradi. Har bir app loyihaning o’z vazifasiga ega bo’lgan qismi. Masalan, Online bozor uchun backend yozganimizda to’lovlar uchun alohida app, mahsulotlar uchun alohida app, foydalanuvchilar uchun alohida app va h.k. qilishimiz mumkin. Shunda loyihamiz tushunishga va boshqarishga osonroq bo’ladi.
Djangoda har bitta app o’zining MVT dizayniga ega. Ya’ni har bir appning ichida alohida biz yuqorida ko’rib chiqqan model, view va template bor.
Django loyihaning tarkibidagi alohida applar
Views requestlarni qabul qilib, response qaytarishini bilib oldik. Lekin, unga qaysi request aynan qaysi viewga murojat qilishini biladigan qism – url dispatcher kerak. Aynan mana shu qism birinchi bo’lib clientdan kelgan requestni kutib oladi va request kelgan URL manziliga qarab kerakli viewga o’tkazib yuboradi. Demak, url dispatcher requestlarni kerakli viewga yetkazib beradi. Url dispatcher url pattern yoki “path”lardan tashkil topgan. Qisqasi, dispatcher requestlarni kutib oladigan manzillar. Masalan, “login/” bu url pattern. Unga bitta view biriktiriladi va har safar client “/login/” qismiga request yuborganda dispatcher uni biriktirilgan viewga yuboradi. Vazifasiga qarab url patternlarni 2 turga ajratish mumkin: to’g’ridan-to’g’ri biror viewga yuboradigan va boshqa url dispatcherga yuboradigan.
Project yaratilgan vaqtda loyiha konfiguratsiyalari turgan folderda url dispatcher avtomatik yaratiladi. Qulaylik uchun odatda, har bir app ichida ham alohida dispatcher yaratilib, bosh dispatcherga ulanadi.
Demak, o’rganganlarimizni bir joyga yig’ib olsak.
Siz browser orqali serverga request yubordingiz. Serverdagi dispatcher requestni tutib oladi va kerakli viewga yuboradi. View esa kerakli amallarni bajarib, zarur bo’lsa models orqali ma’lumotlar bazasiga murojaat qiladi. Keyin ma’lumotlarni kerakli templatega qo’yib, sizga response ko’rinishida yuboradi. Davom etamiz.
Form
Ba’zida foydalanuvchidan ma’lumot olib, o’sha ma’lumot ustida ishlash kerak bo’ladi. Masalan, user ro’yxatdan o’tayotganda undan name, password, email va h.k yuborishni so’raymiz. Agar siz HTML formlardan xabardor bo’lsangiz, buni yaxshi bilasiz.
Django formlar esa xuddi shu formlarning mantiqiy davomi, faqat frontendda emas, backendda yoziladi.
Formlarni qutilarga o’xshatish mumkin. Siz qutini bo’sh holda(ko’pincha) template orqali clientga yuborasiz. Client esa bu qutiga kerakli ma’lumotlarni solib, sizga, ya’ni backendga qaytarib beradi. Siz esa ma’lumotlar solingan qutini ochib, ichida kelgan ma’lumotlarni olasiz.
Djangoda 2 xil turdagi formlar bor. Bu yerda shu haqida qisqacha yozganman.
API
Biz tepada server side rendering, ya’ni frontend qismini ham backendda yozishni ko’rdik. Lekin hozirda aksariyat web dasturlarda backend va frontend qismlari alohida yoziladi.
Frontenddan tashqari, backend serveridan android, desktop applicationlar yoki telegram botlar va h.k.lar foydalanishi mumkin. Masalan, siz OLXning sayti, mobil/IOS ilovasi yoki telegram boti orqali ishlatishingiz mumkin. Lekin bularning barchasi bitta backend server bilan ma’lumot almashadi.
Bu jarayonda bizga API yordamga keladi. U bizga ma’lumot almashish uchun ko’prik vazifasini bajaradi. APIning o’zi esa endpointlardan tashkil topgan. Endpoint biz har kuni ishlatadigan “rozetka”(o’zbekchasini topa olmadim)ga o’xshash narsa. Client unga ulanib, ma’lumot almashadi, xuddi televizor elektrga ulanganidek.
API orqali ma’lumot almashish
Do'stlaringiz bilan baham: |
