#28. Вступ до Django

Загальний погляд на Django, MVC (MVT). URLs.

План

I. Трохи теорії

  1. Клієнт-серверна архітектура
  2. Види мережевих протоколів
  3. HTTP повідомлення
  4. Шаблон проектування MVC
  5. Фреймворк vs Бібліотека
  6. Web Application Server

II. Django

  1. Що таке Django
  2. Архітектура Django
  3. Встановлення Django
  4. Створення проекту
  5. Створення програми
  6. Urls
  7. path()
  8. redirect()

III. Практика / Домашнє завдання
IV. Література (що почитати)

Клієнт-серверна архітектура (детальніше)

Клієнт - локальний комп’ютер на стороні користувача, який виконує відправлення запиту до сервера для можливості надання даних або виконання обчислень.

Параметри, які можуть реалізуватися на стороні клієнта:

  1. Майданчик з надання користувацького інтерфейсу;
  2. Формулювання запиту до сервера та його подальше надсилання;
  3. Отримання підсумків запиту і надсилання додаткової групи команд (запити на додавання, оновлення інформації, видалення групи даних).

Сервер - комп’ютер, на якому зберігається сам додаток. Увесь код, уся логіка, усі додаткові матеріали та довідники.

Параметри, які можуть реалізуватися на стороні сервера:

  1. зберігання, захист і доступ до даних;
  2. Робота з клієнтськими запитами, що надходять;
  3. Процес надсилання відповіді клієнту.

Іноді кажуть “сервер додатка” і “сервер БД”. Це нормально, адже фактично сервер - це просто машина, комп’ютер. А базу і сервер застосунку зазвичай зберігають на різних машинах, заради безпеки. У такому разі, якщо кажуть “сервер додатка” - йдеться про другу ланку схеми.

БД (база даних) - сховище даних.

Архітектура системи клієнт-сервер формулює принципи віртуального спілкування між локальними комп’ютерами, а всі правила і принципи взаємодії знаходяться всередині протоколу.

Мережевий протокол - це особливий набір правил, на підставі якого виконується точна взаємодія між комп’ютерами всередині віртуальної мережі.

Види мережевих протоколів

MAC
Media Access Control (MAC) - це низькорівневий мережевий протокол. Використовується він для ідентифікації мережевих пристроїв. Усі пристрої, які під’єднані до мережі Інтернет, містять свою оригінальну MAC-адресу.

IP
На наступному рівні після MAC розташовується IP - Internet Protocol, що має два основні різновиди IPv4 і IPv6. Він призначає комп’ютерам унікальні IP-адреси, завдяки яким пристрої можуть себе виявляти в мережі.

ICMP, TCP і UDP
Вище IP знаходяться такі протоколи:

  • ICMP (Internet control message protocol), що відповідає за обмін інформацією. Не використовується для передачі даних. Саме ICMP використовується в команді ping і traceroute.
  • TCP (Transmission control protocol). Цей мережевий протокол керує передачею даних. TCP дає гарантію в тому, що всі передані пакети даних будуть прийняті правильно і помилки будуть повністю виключені.
  • UDP (User datagram protocol) схожий на TCP, але працює швидше, оскільки в ньому дані під час отримання не перевіряються. У деяких випадках використання UDP буває цілком достатнім.

TCP/IP - сукупність протоколів передачі інформації. TCP/IP - це особливе позначення всієї мережі, яка функціонує на основі протоколів TCP, а також IP.

HTTP
Hyper Text Transfer protocol - протокол для передачі інформації (гіпертексту), на базі якого функціонують усі сьогоднішні сайти. У його можливості входить процес запитування необхідних даних у віртуально віддаленої системи (файли, веб-сторінки та інше).

HTTPS
HyperText Transfer Protocol Secure - розширення протоколу HTTP для підтримки шифрування з метою підвищення безпеки. Дані в протоколі HTTPS передаються поверх криптографічних протоколів TLS або старішого SSL.

FTP
File Transfer Protocol - протокол передачі інформації з особливого файлового сервера на ПК кінцевого користувача.

POP3, IMAP і SMTP
Протоколи для роботи з електронною поштою.
POP3 (Post Office Protocol Version 3) і IMAP (Internet Message Access Protocol) відповідають за отримання пошти, SMTP (Simple Mail Transfer Protocol) - за надсилання.

HTTP повідомлення (детальніше)

HTTP-повідомлення - це обмін даними між сервером і клієнтом. Є два типи повідомлень: запити, що надсилаються клієнтом, щоб ініціювати реакцію з боку сервера, і відповіді від сервера.
Повідомлення HTTP складаються з текстової інформації в кодуванні ASCII, записаної в кілька рядків.
HTTP запити та відповіді мають близьку структуру. Вони складаються з:

  1. Стартового рядка, що описує запит, або статус (успіх чи збій). Це завжди один рядок.
  2. Довільного набору HTTP заголовків, що визначають запит або описують тіло повідомлення.
  3. Порожнього рядка, який вказує, що вся мета інформація надіслана.
  4. Довільного тіла, що містить дані, які пересилаються із запитом (наприклад, вміст HTML-форми) або документ, що надсилається у відповідь. Наявність тіла і його розмір визначається стартовим рядком і заголовками HTTP.

Запити HTTP (Request)

Складаються з:

  1. Стартового рядка (start line)
  2. Заголовки (headers)
  3. Тіло (body) - може не бути

Відповіді HTTP (Response)

Складаються з:

  1. Рядок статусу (status line)
  2. Заголовки (headers)
  3. Тіло (body)

Методи HTTP запиту

Метод GET

Використовується для запиту вмісту зазначеного ресурсу. Наприклад, отримати дані, файл або будь-яку іншу інформацію, браузер при наборі url https://uk.wikipedia.org або http://www.example.com/index.html?id=1&name=value використовує саме GET запит, може передавати змінні в query параметрі (у прикладі ?id=1&name=value це query параметри, починається з символу ?, наступний параметр додається за допомогою символу & у цьому прикладі, параметр {‘id’: '1, ‘name’: ‘value’}).

Зазвичай не використовується для надсилання даних, тільки для отримання певної інформації. Наприклад отримання коментарів до посту в блозі.

Метод POST

Застосовується для передавання користувацьких даних заданому ресурсу. Наприклад, у блогах відвідувачі зазвичай можуть вводити свої коментарі до записів у HTML-форму, після чого їх передають серверу методом POST, і він поміщає їх на сторінку. При цьому передані дані (у прикладі з блогами - текст коментаря) включаються в тіло запиту. Аналогічно за допомогою методу POST зазвичай завантажуються файли на сервер. Може містити багато даних або файлів (або і те, і інше).

Метод PUT

Застосовується для оновлення даних по заданому ресурсу ціликом, наприклад, зміна коментаря. Може містити багато даних або файлів (або і те й інше).

Метод PATCH

Майже аналогічний методу PUT, але застосовується для часткової зміни об’єкта. Припустимо зміни даних в профілі в соц мережі, при зміні імейла, нам не потрібно змінювати весь профіль, тільки поле імейл. Може містити багато даних або файлів (або і те й інше).

Метод DELETE

Використовується для видалення об’єктів, зазвичай не приймає дані, як і метод гет. Приклад, все той же коментар.

Існують і інші запити, які використовують рідше і з іншими призначеннями, їх і більш детально ці запити, ми розглянемо на іншому занятті.

Описані запити використовують для стандартних CRUD операцій:

  • Create - POST
  • Retrieve - GET
  • Update - PUT/PATCH
  • Delete - DELETE

Коди відповіді HTTP (детальніше)

Код відповіді (стану) HTTP показує, чи був успішно виконаний певний HTTP-запит. Коди згруповані в 5 класів:

  1. Інформаційні 100 - 199
  2. Успішні 200 - 299
  3. Перенаправлення 300 - 399
  4. Клієнтські помилки 400 - 499
  5. Серверні помилки 500 - 599

Шаблон проектування MVC (Model-View-Controller)

MVC - це патерн проєктування веб-додатків, який містить у собі 3 блоки. При використанні MVC на три окремі компоненти розділені модель даних додатка, призначений для користувача інтерфейс і логіка взаємодії користувача з системою, завдяки чому модифікація одного з цих компонентів чинить мінімальний вплив на інші або не чинить його зовсім.

Основна мета застосування MVC полягає в поділі даних і бізнес-логіки від візуалізації. За рахунок такого поділу підвищується можливість повторного використання програмного коду: наприклад, додати представлення даних будь-якого наявного маршруту не тільки у вигляді HTML, а й у форматах JSON, XML, PDF, XLSX стає дуже просто та не вимагає змін шару бізнес-логіки вихідного маршруту. Також спрощується і супровід програмного коду: внесення змін до зовнішнього вигляду, наприклад, не відображаються на бізнес-логіці, а зміни бізнес-логіки не зачіпають візуалізацію.

Концепція MVC розділяє дані, подання та обробку дій користувача на компоненти:

  • Модель / Model - містить у собі дані та методи роботи з цими даними, реагує на запити з контролера, повертаючи дані та/або змінюючи свій стан. При цьому модель не містить у собі інформації про способи візуалізації даних або формати їх подання, а також не взаємодіє з користувачем безпосередньо.

  • Вигляд (Представлення) / View - відповідає за відображення інформації (візуалізацію). Одні й ті самі дані можуть представлятися різними способами і в різних форматах. Наприклад, колекцію об’єктів за допомогою різних подань можна представити на рівні користувацького інтерфейсу як у табличному вигляді, так і списком; на рівні API можна експортувати дані як у JSON, так і в XML або XSLX.

  • Контролер / Controller - забезпечує зв’язок між користувачем і системою, використовує модель і подання для реалізації необхідної реакції на дії користувача. Як правило, на рівні контролера здійснюється фільтрація отриманих даних і авторизація - перевіряються права користувача на виконання дій або отримання інформації.

За цим же принципом працює і Django, але в дещо зміненій, тільки за термінами формі, патерн називається MVT (Model - View - Template), де View відіграє роль контролера, а Template роль відображення, але суть при цьому зберігається.

  • enter image description here

А чи є інші патерни?
Звичайно, але це вже виходить за рамки програми.

Фреймворк vs Бібліотека

Фреймворк (framework - кістяк, каркас, рама, структура) - програмна платформа, що визначає структуру програмної системи; програмне забезпечення, що полегшує розробку та об’єднання різних компонентів великого програмного проєкту.

Бібліотека (від англ. library) у програмуванні - збірка підпрограм або об’єктів, що використовуються для розробки програмного забезпечення (ПЗ). У Python те саме, що й модуль.

“Фреймворк” відрізняється від поняття бібліотеки тим, що бібліотека може бути використана в програмному продукті просто як набір підпрограм близької функціональності, не впливаючи на архітектуру програмного продукту та не накладаючи на неї жодних обмежень.
Натомість "фреймворк" диктує правила побудови архітектури застосунку, задаючи на початковому етапі розроблення поведінку за замовчуванням - “каркас”, який треба буде розширювати та змінювати, відповідно до зазначених вимог.
Також, на відміну від бібліотеки, яка об’єднує в собі набір близької функціональності, - “фреймворк” може містити в собі допоміжні програми, бібліотеки коду, мову сценаріїв та інше ПЗ, яке полегшує розробку та об’єднання різних компонентів великого програмного проєкту.

Web application (or web app)

Вебзастосунок (іноді вебдодаток) — клієнт-серверний додаток, у якому клієнт взаємодіє з веб-сервером за допомогою браузера. Браузер може бути реалізацією так званих тонких клієнтів — логіка застосунку зосереджується на сервері, а функція браузера полягає переважно у зображенні інформації, завантаженої мережею з сервера, і передачі назад даних користувача. Однією з переваг такого підходу є той факт, що клієнти не залежать від конкретної операційної системи користувача, тому вебзастосунки є міжплатформовими сервісами.

Web Server

(до 2019 — веб-сервер, англ. Web Server) — це сервер, що приймає HTTP-запити від клієнтів, зазвичай веббраузерів, видає їм HTTP-відповіді, зазвичай разом з HTML-сторінкою, зображенням, файлом, медіа-потоком або іншими даними. Вебсервер — одна із основ Всесвітньої павутини.

Вебсервером називають як програмне забезпечення, що виконує функції вебсервера, так і комп’ютер, на якому це програмне забезпечення працює.

Клієнти дістаються вебсервера за URL-адресою потрібної їм вебсторінки або іншого ресурсу.

Додаткові функції

  • Ведення журналу серверу про звернення користувачів до ресурсів
  • Автентифікація користувачів
  • Підтримка сторінок, що динамічно генеруються
  • Підтримка HTTPS для захищених з’єднань з клієнтами

Існує багато вебсерверів. Сьогодні найпоширенішими є:

  • Apache HTTP Server — найпоширеніший у світі вебсервер. Найстаріший та підтримує багато
    модулей.
  • Nginx — вільний вебсервер з фокусом на продуктивність. Часто
    використовується як проксі-сервер та для роздачі статичних файлів.
  • lighttpd — вільний вебсервер з фокусом на швидкість та маленький
    розмір.
  • IIS — вебсервер компанії Microsoft для Microsoft Windows

WSGI

WSGI (англ. Web Server Gateway Interface, вимовляється як візґі) — стандарт взаємодії між Python-програмою, яка виконується на стороні сервера, і самим вебсервером, наприклад, Apache.

В Python існує велика кількість різного роду вебфреймворків, інструментаріїв і бібліотек. У кожного з них — власний метод встановлення та налаштування, вони часто написані так, що не можуть взаємодіяти між собою. Це може стати проблемою, бо вибір фреймворку може обмежити вибір вебсервера і навпаки.

WSGI надає простий і універсальний інтерфейс для взаємодії між більшістю вебсерверів і вебзастосунками чи фреймворками.

Сьогодні найпоширенішими WSGI cерверами є:

  • Gunicorn
  • uWSGI

Монолітна vs Мікросервісна архітектура

enter image description here

Що таке монолітна архітектура?

Монолітну архітектуру розглядають як традиційний метод розробки додатків. Додаток у монолітній архітектурі розробляється як єдиний пакет. Розробка нормального додатка починається з модульної багаторівневої або шестикутної архітектури. Ця архітектура складається з таких типів шарів:

  • Рівень представлення. Це рівень графічного інтерфейсу користувача, який обробляє запити протоколу передавання гіпертексту (HTTP) з використанням HTML або XML/JSON.
  • Рівень бізнес-логіки: бізнес-логіка додатка присутня на цьому рівні.
  • Рівень доступу до бази даних: усі звернення до бази даних, включно з SQL та NoSQL додатками, відбуваються на цьому рівні.
  • Рівень інтеграції додатків : усі інтеграції програмного забезпечення з іншими системами відбуваються на цьому рівні.

Незважаючи на те, що монолітна архітектура має логічну багаторівневу архітектуру, кінцеві додатки будуть упаковані в один моноліт і потім розгорнуті таким чином. Монолітним додаткам не вистачає належної модульності, і вона має лише одну кодову базу.

Що таке мікросервісна архітектура?

З іншого боку, мікросервісна архітектура дотримується модульного підходу для розробки різних додатків. Мікросервісна архітектура включає в себе набір невеликих, незалежних і автономних модулів, які виконують різні послуги. Кожен сервіс повинен мати можливість самостійної реалізації відповідних бізнес-одиниць.
Монолітна архітектура - це єдине ціле. Але в мікросервісній архітектурі є група невеликих незалежних блоків, які спільно працюють як один додаток. Усі функціональні можливості застосунку розбиті на окремі та незалежні розгортаються модулі, які взаємодіють один з одним за допомогою методів, званих інтерфейсами прикладного програмування (API). Кожну зі служб в архітектурі мікросервісів можна легко масштабувати, розгортати та оновлювати незалежно.

Мікросервісна архітектура - це слабко пов’язана архітектура, кожен компонент є незалежним по відношенню один до одного. Для їх кодування можна використовувати кілька мов програмування. Крім того, вони можуть використовувати інший тип зберігання для зберігання даних.

Що таке Django?

enter image description here


Джанго Рейнхардт (циг. Django Reinhardt; справжнє ім’я Жан Ренарт, фр. Jean Reinhardt; 23 січня 1910 - 16 травня 1953) - французький джазовий гітарист-віртуоз, один із засновників стилю “джаз-мануш”. Прізвисько Рейнхардта “Django” циганською мовою означає “я прокинувся”.

Django - це високорівневий Python веб-фреймворк, який дає змогу швидко створювати безпечні та підтримувані веб-сайти. Створений досвідченими розробниками, Django бере на себе більшу частину клопоту веб-розробки, тому ви можете зосередитися на написанні свого веб-додатка без необхідності винаходити велосипед. Він безкоштовний і з відкритим вихідним кодом, має зростаючу й активну спільноту та чудову документацію.
Основний інформаційний ресурс Django.
Документація Англійською офф і не офф переклад
Проект підтримується організацією Django Software Foundation.
Один з основних принципів фреймворку - DRY (англ. Don’t repeat yourself)

Django був розроблений у період з 2003 по 2005 рік командою, яка займалася створенням і обслуговуванням газетних веб-сайтів. Після створення кількох сайтів, команда почала повторно використовувати безліч спільного коду і шаблонів проектування. Цей спільний код еволюціонував у веб-фреймворк, який перетворився на проект “Django” з відкритим вихідним кодом у липні 2005 року.
Перший реліз (1.0) відбувся у вересні 2008 року.

Django допомагає писати програмне забезпечення, яке буде:

Повним

Django слідує філософії “Все включено” і надає майже все, що розробники можуть захотіти зробити “з коробки”. Оскільки все, що вам потрібно, є частиною єдиного “продукту”, все це бездоганно працює разом, відповідає послідовним принципам проектування та має велику й актуальну документацію.

Різнобічним

Django може бути (і був) використаний для створення практично будь-якого типу веб-сайтів - від систем управління контентом і wiki до соціальних мереж і новинних сайтів. Він може працювати з будь-яким клієнтським середовищем і може доставляти контент практично в будь-якому форматі (включно з HTML, RSS-каналами, JSON, XML тощо).
Хоча Django надає рішення практично для будь-якої функціональності, яка вам може знадобитися (наприклад, для кількох популярних баз даних, шаблонізаторів тощо), внутрішньо його також можна розширити сторонніми компонентами, якщо це необхідно.

Безпечним

Django допомагає розробникам уникнути багатьох поширених помилок безпеки, надаючи фреймворк, розроблений щоб “робити правильні речі” для автоматичного захисту сайту. Наприклад, Django надає безпечний спосіб управління обліковими записами користувачів і паролями, уникаючи поширених помилок, як-от розміщення інформації про сеанс у файли cookie, де вона є вразливою (натомість файли cookie містять лише ключ, а фактичні дані зберігаються в базі даних), або безпосереднє зберігання паролів замість хешу пароля.
Хеш пароля - це значення фіксованої довжини, створене шляхом обробки пароля через криптографічну хеш-функцію. Django може перевірити правильність введеного пароля, пропустивши його через хеш-функцію і порівнявши висновок зі збереженим значенням хеша. Завдяки “односторонньому” характеру функції, навіть якщо збережене хеш-значення скомпрометоване, зловмиснику буде складно визначити вихідний пароль.
Django, за замовчуванням, забезпечує захист від багатьох вразливостей, включно з SQL-ін’єкцією, міжсайтовим скриптингом, підробкою міжсайтових запитів.

Масштабованим

Django використовує компонентну “shared-nothing” архітектуру (кожна її частина незалежна від інших і, отже, може бути замінена або змінена, якщо це необхідно). Чіткий поділ частин означає, що Django може масштабуватися під час збільшення трафіку, шляхом додавання обладнання на будь-якому рівні: сервери кешування, сервери баз даних або сервери додатків. Одні з найбільш завантажених сайтів успішно масштабували Django (наприклад, Instagram і Disqus, якщо назвати тільки два з них).

Зручним у супроводі

Код Django написаний з використанням принципів і шаблонів проектування, які заохочують створення підтримуваного і повторно використовуваного коду. Зокрема, у ньому використовується принцип “Don’t Repeat Yourself” (DRY, “не повторюйся”), тож немає непотрібного дублювання, що скорочує обсяг коду. Django також сприяє групуванню пов’язаних функціональних можливостей у повторно використовувані “додатки” і, на нижчому рівні, групує пов’язаний код у модулі (відповідно до шаблону Model View Controller (MVC)).

Переносним

Django написаний на Python, який працює на багатьох платформах. Це означає, що ви не прив’язані до будь-якої конкретної серверної платформи і можете запускати додатки на багатьох версіях Linux, Windows і Mac OS X. Крім того, Django добре підтримується багатьма веб-хостингами, які часто надають певну інфраструктуру і документацію для розміщення сайтів Django.

Можливості Django

  • ORM, API доступу до БД із підтримкою транзакцій
  • вбудований інтерфейс адміністратора, з уже наявними перекладами багатьма мовами
  • диспетчер URL на основі регулярних виразів
  • розширювана система шаблонів із тегами та успадкуванням
  • система кешування
  • інтернаціоналізація
  • архітектура додатків, що підключається, які можна встановлювати на будь-які Django-сайти
  • “generic views” - шаблони функцій контролерів
  • авторизація та аутентифікація, підключення зовнішніх модулів аутентифікації.
  • система фільтрів (“middleware”) для побудови додаткових обробників запитів, як-от, наприклад, фільтри для кешування, стиснення, нормалізації URL і підтримки анонімних сесій, що входять до дистрибутиву
  • бібліотека для роботи з формами (успадкування, побудова форм за наявною моделлю БД)
  • вбудована автоматична документація за тегами шаблонів і моделями даних, доступна через адміністративний додаток

Сайти, що працюють на фреймворку Django

Історія Django налічує вже близько 10 років. За цей період його використовували в продакшені на безлічі топових сайтів. Ось деякі видатні приклади:

  • Pinterest
  • Mozilla
  • Bitbucket
  • Udemy
  • The Onion
  • Disqus
  • Washington Post
  • NASA
  • Spotify
  • Instagram
  • National Geographic
  • The Guardian
  • JSFiddle

Архітектура Django

  • URLs: Хоча можна обробляти запити з кожної URL-адреси за допомогою однієї функції, набагато зручніше писати окрему функцію для обробки кожного ресурсу. URL-маршрутизатор використовується для перенаправлення HTTP-запитів у відповідне подання на основі URL-адреси запиту. Крім того, URL-маршрутизатор може витягувати дані з URL-адреси відповідно до заданого шаблону і передавати їх у відповідну функцію відображення (view) у вигляді аргументів.
  • View: це функція обробника запитів, яка отримує HTTP-запити та повертає відповіді. Функція view має доступ до даних, необхідних для задоволення запитів, і делегує відповіді в шаблони через моделі.
  • Models: Моделі являють собою об’єкти Python, які визначають структуру даних додатка і надають механізми для управління (додавання, зміни, видалення) і виконання запитів до бази даних.
  • Templates: це текстовий файл, що визначає структуру або розмітку сторінки (наприклад HTML-сторінки), з полями для підстановки, які використовуються для виведення актуального вмісту. View може динамічно створювати HTML-сторінки, використовуючи HTML-шаблони і заповнюючи їх даними з моделі (_model). _Шаблон може бути використаний для визначення структури файлів будь-яких типів, не обов’язково HTML.

Версії

Django Release Cycle
Django release roadmap

Встановлення Django

Створення віртуального оточення

python3 -m venv env
або
virtualenv -p python3 env

Якщо модуль відсутній, його доведеться встановити.

Активація:
У Windows командою:

env\Scripts\activate.bat

У Linux або MacOS:

source env/bin/activate

Деактивація

deactivate

Встановлення

pip install django

Створення проекту

django-admin startproject mysite .

Ця команда створює новий проєкт, і заповнює його базово потрібними файлами, давайте розглянемо їх.
Крапка . важлива, тому що говорить скрипту встановити Django у вашому поточному каталозі (який і позначається скорочено крапкою .)

Структура файлів:

mysite /
    manage.py
    mysite /
	    asgi.py
        __init__.py
        settings.py
        urls.py
        wsgi.py

manage.py - файл-утиліта за допомогою якого ми будемо взаємодіяти з багатьма частинами Django з консолі

Усередині папки mysite:

__init__.py - Порожній файл, який говорить Python-у, що цей каталог повинен розглядатися як пакет Python-а

settings.py - Налаштування та конфігурації проєкту.

urls.py - URL-и для цього проєкту.

wsgi.py - Web Server Gateway Interface стандарт взаємодії між Python-програмою, що виконується на стороні сервера, і самим веб-сервером.
Файл відповідає за вхідну точку сервера - дає змогу запускати код як сайт.

asgi.py - Asynchronous Server Gateway Interface - клієнт-серверний протокол взаємодії веб-сервера і додатка, подальший розвиток технології WSGI. Порівняно з WSGI надає стандарт як для асинхронних, так і для синхронних застосунків, з реалізацією зворотної сумісності WSGI і декількома серверами та платформами застосунків.

Проверимо працездатність.

У консолі запустимо локальний “сервер” із папки з нашим “сайтом” (у моєму прикладі mysite)

python manage.py runserver

Не закриваючи консоль (сервер має працювати), відкриваємо в браузері http://127.0.0.1:8000/

127.0.0.1.1 - це локальний хост, а :8000 - це номер порту, на якому запущено процес. 127.0.0.1.1 можна замінити на 0.0.0.0.0 або слово localhost, усі три варіанти практично взаємозамінні.

Якщо ви все зробили правильно, то в браузері повинні побачити, щось таке:

Створення програми

Архітектура додатка передбачає використання окремих модулів як частини сайту (буває один на весь сайт, а бувають і тисячі), такі модулі називаються додатками, і саме в них пишеться “суть” сайту.

python manage.py startapp myapp

Команда створить вам папку з вашим додатком, давайте розберемо її докладніше

myapp/
    __init__.py
    admin.py
    apps.py
    migrations/
        __init__.py
    models.py
    tests.py
    views.py

__init__.py - порожній файл, який говорить Python-у, що цей каталог повинен розглядатися як пакет Python-а

admin.py - заготовка під адмінку

apps.py - інформація про застосунок (потрібно за великої кількості застосунків, для зручності)

migrations - міграції бази даних.

models.py - моделі.

tests.py - тести.

views.py - контролер додатка.

Реєстрація папки з додатком

Після створення застосунку нам потрібно зареєструвати його в проєкті, щоб різні утиліти зачіпали його своєю дією (наприклад, під час додавання моделей у базу даних). Додатки реєструються додаванням їхніх назв до списку INSTALLED_APPS у налаштуваннях проєкту (який, як ми пам’ятаємо, називається settings.py).

Відкрийте файл settings.py і знайдіть у ньому список INSTALLED_APPS . Потім додайте новий рядок у кінець списку.

INSTALLED_APPS = [  
    'django.contrib.admin',  
    'django.contrib.auth',  
    'django.contrib.contenttypes',  
    'django.contrib.sessions',  
    'django.contrib.messages',  
    'django.contrib.staticfiles',  
    'myapp',
]

Сторонні додатки підключаються сюди ж.

Urls

Для початку змінимо файл views.py

from django.http import HttpResponse

def index(request):
    return HttpResponse("Hello, world!")

Для роботи нашого додатка створюємо додатковий файл у папці з додатком і назвемо його urls.py

myapp/urls.py

from django.urls import path

from .views import index

urlpatterns = [
    path('', index, name='index'),
]

У файлі з урлами створимо посилання на урли додатка

mysite/urls.py

from django.urls import include, path

urlpatterns = [
    path('', include('myapp.urls')),
]

Тепер відкриємо наш “сайт” і введемо в адресний рядок http://127.0.0.1:8000/

Функція path()

path(route, view, kwargs=None, name=None)
Повертає елемент для включення в urlpatterns.

Конвертери шляху

За замовчуванням доступні такі конвертери шляху:

  • str - відповідає будь-якому непорожньому рядку, за винятком роздільника шляху, ‘/’. Це значення за замовчуванням, якщо перетворювач не включено у вираз.
  • int - відповідає нулю або будь-якому позитивному цілому числу. Повертає int.
  • slug - відповідає будь-якому рядку заголовка, що складається з літер або цифр ASCII, а також символів дефіса і підкреслення. Наприклад, build-your-1st-django-site.
  • uuid - відповідає форматованому UUID. Щоб запобігти зіставленню кількох URL-адрес з однією і тією ж сторінкою, необхідно використовувати дефіси, а літери повинні бути малими. Например, 075194d3-6885-417e-a8a8-6c931e272f00. Повертає екземпляр UUID.
  • path - відповідає будь-якому непорожньому рядку, включно з роздільником шляху, '/'. Це дозволяє вам зіставляти повний шлях URL, а не сегмент шляху URL, як у випадку зі str.

Застосування path
Оновимо наш urls.py:

from django.urls import include, path
from myapp.views import index, main_article, uniq_article, article

urlpatterns = [
    path('my_url/', include('myapp.urls')),
    path('article/', main_article, name='mail_article'),
    path('article/33/', uniq_article, name='uniq_article'),
    path('article/<int:article_id>/', article, name='article'),
    path('article/<int:article_id>/<slug:name>', article, name='article_name'),
    path('', index, name='index'),
]

І додамо до myapp/views.py:

def main_article(request):
    return HttpResponse('There will be a list with articles')

def uniq_article(request):
    return HttpResponse('This is uniq answer for uniq value')

def article(request, article_id, name=''):
    return HttpResponse(
        "This is an article #{}. {}".format(article_id, "Name of this article is {}".format(
            name) if name else "This is unnamed article"))

Давайте розберемо докладніше.

Ми описали два статичних урла article/ і article/33/ і два динамічних article/<int:article_id>/ і article/<int:article_id>/<slug:name>/, причому в якості обробника динамічних урлів, ми вказали одну й ту саму функцію article, у якій зазначили, що прийматимуться два параметри article_id та name, і водночас name не є обов’язковим, оскільки має значення за замовчуванням. оскільки має значення за замовчуванням.

Використання регулярних виразів

Якщо синтаксису шляхів і перетворювачів недостатньо для визначення шаблонів URL-адрес, ви також можете використовувати регулярні вирази. Для цього використовуйте re_path() замість path().
Також для зворотної сумісності з django першої версії є функція url, яка є просто посиланням на re_path.
У регулярних виразах Python для іменованих груп регулярних виразів використовується синтаксис (?P<name>pattern), де name - ім’я групи, а pattern - деякий шаблон для зіставлення.

Ось приклад URLconf із попереднього, переписаний із використанням регулярних виразів:

from django.urls import path, re_path

from . import views

urlpatterns = [
    path('articles/2003/', views.special_case_2003),
    re_path(r'^articles/(?P<year>[0-9]{4})/$', views.year_archive),
    re_path(r'^articles/(?P<year>[0-9]{4})/(?P<month>[0-9]{2})/$', views.month_archive),
    re_path(r'^articles/(?P<year>[0-9]{4})/(?P<month>[0-9]{2})/(?P<slug>[\w-]+)/$', views.article_detail),
]

redirect()

from django.shortcuts import redirect

redirect(to, *args, permanent=False, **kwargs)

Повертає HttpResponseRedirect на відповідну URL-адресу для переданих аргументів.

Аргументами можуть бути:

  • Модель: буде викликано функцію моделі get_absolute_url().
  • Ім’я подання, можливо з аргументами: reverse(), буде використовуватися для зворотного дозволу імені.
  • Абсолютна або відносна URL-адреса, яка буде використовуватися як є для місця розташування перенаправлення.

За замовчуванням видає тимчасове перенаправлення; передайте permanent=True, щоб виконати постійне перенаправлення.

Приклади

Ви можете використовувати функцію redirect() різними способами.

  1. Передаючи деякий об’єкт; буде викликано метод цього об’єкта get_absolute_url() для визначення URL перенаправлення:
    from django.shortcuts import redirect

def my_view(request):
    ...
    obj = MyModel.objects.get(...)
    return redirect(obj)
  2. Шляхом передачі імені подання і, можливо, деяких позиційних або ключових аргументів; URL-адресу буде перетворено у зворотному порядку з використанням методу reverse():
    def my_view(request):
    ...
    return redirect('some-view-name', foo='bar')
  3. Передаючи задану URL-адресу для перенаправлення на:
    def my_view(request):
    ...
    return redirect('/some/url/')
    Це також працює з повними URL:
    def my_view(request):
    ...
    return redirect('https://example.com/')

За замовчуванням redirect() повертає тимчасове перенаправлення. Всі перераховані вище форми приймають permanent аргумент; якщо встановлено значення True, буде повернуто постійне перенаправлення:

def my_view(request):
    ...
    obj = MyModel.objects.get(...)
    return redirect(obj, permanent=True)

Додатково

  1. Налаштування запуску django сервера в PyCharm
  2. Створення django проекту в PyCharm

Практика / Домашнє завдання:

  1. Навчитися створювати та запускати django проєкт через консоль і PyCharm

  2. Створити новий проєкт і новий додаток

  3. Створити в ньому всю необхідну структуру, для урлів
    http://127.0.0.1:8000/,
    http://127.0.0.1:8000/acricles ,
    http://127.0.0.1:8000/acrticles/archive,
    http://127.0.0.1:8000/users

  4. Створити структуру для динамічних урлів: http://127.0.0.1:8000/article/<int:article_number>, http://127.0.0.1:8000/article/<int:article_number>/archive, http://127.0.0.1:8000/article/<int:article_number>/<slug:slug_text>, http://127.0.0.1:8000/users/<int:user_number>>.

  5. Створити url (у urls, не функцію у views) , який прийматиме як параметр коректний номер українського мобільного телефону, 0501231214 - коректно, 0751231212 - ні.

  6. Створити url (у urls, не функцію у views), який прийматиме параметр вигляду 4 символи від 1 до 9, або від a до f, знак дефіса і ще 6 символів, наприклад /34f1-1ac498/

Повертати урли можуть все що завгодно, головне, щоб вони працювали.

Література (що почитати)

  1. Клієнт-серверна архітектура в картинках
  2. Мережеве та Інтернет-програмування -> Теорія
  3. HTTP повідомлення
  4. Коди відповіді HTTP
  5. URL dispatcher