Сайт Блогу

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

Основні функції

Реєстрація та Аутентифікація Користувачів

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

Керування Статтями

Автори матимуть можливість створювати, редагувати та видаляти статті в рамках додатка. Система надасть зручний редактор. Крім того, автори зможуть категоризувати статті, присвоюючи їм відповідні теми.

Підписка на Теми:

Автори матимуть можливість створювати, редагувати та видаляти статті в рамках додатка. Система надасть зручний редактор. Крім того, автори зможуть категоризувати статті, присвоюючи їм відповідні теми.

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

Ось шаблон стартового репозиторію, який може допомогти: Starter template.

Виклик: Функціональні представлення

Зараз немає потреби повертати фактичний вміст. Просто переконайтеся, що всі маршрути доступні та надають правильні дані. Використовуйте будь-що, що ви хочете повернути в HTTP-відповіді.

  • /about/: надає звичайний текст для користувача, що описує функції сайту django.

  • /: Головна сторінка сайту. Тут буде перелік блогів, опублікованих через сайт Django.

  • /<article>/: Представлення деталей однієї статті. URL містить динамічну частину. Вона буде використовуватися для отримання однієї статті з бази даних.

  • /<article>/comment/: Це представлення буде використовуватися для додавання коментарів до статті.

  • /create/: Форма створення статті.

  • /<article>/update/: Представлення для оновлення існуючих даних статті.

  • /<article>/delete/: Представлення для підтвердження видалення статті.

  • /topics/: Перелік доступних тем на сайті.

  • /topics/<topic>/add/: Додати обрану тему до списку обраних тем.

  • /topics/<topic>/remove/: Видаляє вибрану тему з обраних.

  • /topics/<topic>/subscribe/: Представлення для підписки на тему.

  • /topics/<topic>/unsubscribe/: Представлення для відписки від теми.

  • /profile/<str:username>/: Особиста сторінка користувача сайту.

  • /set-password/: Цей маршрут буде використовуватися для зміни облікових даних користувачів.

  • /set-userdata/: Цей маршрут буде використовуватися для зміни даних користувачів.

  • /deactivate/: Представлення для деактивації облікового запису (видалення).

  • /register/: Сторінка з формою для реєстрації нового користувача.

  • /login/: Сторінка з формою для логіна.

  • /logout/: Логаут. Має перенаправляти користувача назад на домашню сторінку..

Попередження

Додаткові завдання

  • /archive/<int:year>/<int:month>/: Це представлення надає список статей, опублікованих у певному місяці певного року. Це представлення повинно застосовувати перевірку дати та викидати помилку Http404 для неприпустимих шляхів. Припустимою датою є 4-значний формат року, за яким слідує 1 або 2 цифри, що представляють місяць. Діапазон місяця повинен бути обмежений [1..12], ведучий нуль може бути пропущений. Приклади правильних URL-адрес:

    /archive/2023/1/
/archive/2023/01/
/archive/2023/10/

Завдання: моделі даних

Підказка

Для створення деяких фіктивних даних можна використовувати Django Admin. Щоб отримати доступ до адміністративного розділу, вам потрібно створити суперкористувача. Найпростіший спосіб зробити це - використовувати команду Django:

python manage.py createsuperuser

Основне

  • Кожна модель буде зареєстрована на сторінці адміністрації сайту.

Тема статті

  • Ось проста модель, що містить інформацію про тему:

    • назва теми (унікальне значення, не більше 64 символів)

    • короткий опис теми (не більше 255 символів)

Стаття

  • Стаття вимагає наявності заголовка (не більше 255 символів).

  • Стаття вимагає наявності змісту (принаймні 255 символів).

  • Дата створення буде автоматично генеруватися при створенні статті і не буде оновлюватися пізніше.

  • Дата оновлення буде оновлюватися при кожному збереженні статті.

Коментар до статті

  • Коментар вимагає наявності дати створення (автоматично генерується).

  • Коментар вимагає наявності тексту повідомлення.

Відносини

Примітка

Стандартна модель користувача Django буде використовуватися наразі. Для застосування посилання на модель передайте "auth.User" як пов’язану модель. Користувачі можуть бути створені через адміністративну сторінку. Ви також можете посилатися на ту саму модель, як показано нижче:

from django.contrib.auth import get_user_model
from django.conf import settings

UserModel = get_user_model            # option 1
UserModel = settings.AUTH_USER_MODEL  # option 2
UserModel = "auth.User"               # option 3

  • article та topics мають багато-до-багатьох відношення.

  • article та user мають один-до-багатьох відношення. У статті може бути лише один автор, але користувачі можуть створювати стільки статей, скільки їм потрібно.

  • article та comment мають один-до-багатьох відношення. Стаття може бути контейнером для багатьох коментарів, але коментар пов’язаний лише з однією статтею.

  • comment та user мають один-до-багатьох відношення. Це схоже на відношення стаття - користувач.

  • topic та user використовують відношення багато-до-багатьох. Один користувач може вибрати будь-яку кількість тем, і навпаки. Це відношення представляє теми, які вибрані певним користувачем блогу. Крім того, це надає додаткову опцію позначити деякі з вибраних тем прапорцем notify, щоб отримувати розсилки про оновлення зазначених тем. Відмінність між prefer (вибір) та notify (сповіщення) полягає в тому, що prefer впливає на список статей для користувача, а notify відповідає за розсилку новин для користувача.

UML діаграми

erDiagram topic { string title string description } article { string title text content date created_at date updated_at } comment { datetime created_at text message } article ||--|{ comment: contains topic }|--o{ article: contains topic }o--o{ user: prefers user }|--|| article: author user }|--|| comment: author

Завдання: ORM

Оновіть існуючі подання, щоб представити сутності, які фактично зберігаються в базі даних проекту.

  • /: повинен представляти список існуючих статей.

  • /<article>/: повинен представляти окрему існуючу статтю.

  • Вью для перегляду окремої статті повинен отримувати зв’язані коментарі.

  • /profile/<str:username>/: повинен містити інформацію про користувача та список статей, написаних цим користувачем.

  • Усі ресурси, пов’язані з окремою сутністю (деталі, оновлення, видалення, профіль) мають викликати Http404 у випадку, якщо сутність не вдалося отримати.

Підказка

Звичайно, функції/класи, що підтримують певну специфічну бізнес-логіку, розумно зберігати в окремому модулі з назвою services.py або utils.py всередині директорії додатку.

Попередження

Додаткові завдання

  • Створіть сервіс для того, щоб отримувати статі у вигляді відсортованому згідно вподобань зазначеного користувача. Це означає, що чим більше тем зазначених у статті співпадає з вподобаннями користувача, тим ближче вона до початку видачі.

Завдання: Шаблони

Підказка

Корисне посилання: Bootstrap template

Важливо

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

Основне

  • Усі шаблони повинні успадковувати base.html шаблон.

  • Кожна сторінка має описовий тег HTML заголовка, включаючи суфікс | Blog, наприклад, «Articles | Blogs», «Sample | Blog», «Login | Blog» і т.д.

  • Кожна сторінка повинна містити посилання на головну сторінку (шлях URL /).

  • Кожна сторінка містить список зареєстрованих тем. Кожне представлення цього типу фільтрує лише статті відповідної теми. Це слід реалізувати за допомогою власного обробника контексту шаблону (template context processor).

  • Замініть блок вмісту (content block) для сторінки about на деякий статичний вміст.

  • Шаблони рівня застосунків розташовуватися у відповідних застосунках.

Попередження

Додаткові завдання

  • Кожна сторінка має містити список посилань на перегляди архіву за останній рік.

  • Кожна сторінка повинна містити блок(и) включення з такими посиланнями:

    • /register/: форма реєстрації нового користувача

    • /login/: форма логіна користувача

    • /create/: форма створення статті

Список статей

  • Головна сторінка містить список опублікованих статей.

  • Кожен елемент статті відображається за допомогою власного шаблонного тегу.

  • Шаблонний тег article відображає інформацію про об’єкт статті:

    • заголовок статті

    • зміст статті (обрізаний до ~50 символів)

    • дата створення статті

    • пов’язані теми (3 або менше)

    • кількість коментарів до статті

Деталі статті

Важливо

Оновлення та видалення статей не будуть впливати на дані наразі.

  • На сторінці деталей статті мають бути посилання на оновлення або видалення поточної статті.

  • Сторінка надає інформацію про статтю:

    • Заголовок статті

    • Дата створення

    • Ім’я автора

    • Пов’язані теми

    • Вміст статті

  • Сторінка містить список пов’язаних коментарів.

  • Кожен коментар містить:

    • Ім’я автора

    • Час створення коментаря

    • Текст комментаря

Строніка профілю

  • Сторінка автора містить інформацію про автора:

    • Ім’я

    • Прізвище

    Додайте більше інформації за бажанням.

  • Сторінка автора містить список статей, створених цим автором.

  • Сторінка автора містить кнопки/посилання для зміни користувача та пароля або деактивації облікового запису користувача.

Форми

Важливо

Наразі немає потреби додавати фактичні форми. Вони будуть створені Django. Цей розділ описує кінцевий вигляд цих сторінок. Для майбутнього використання достатньо створити окремі шаблони.

  • Сторінка /register/ містить форму реєстрації нового користувача. Вона повинна отримувати введені дані від користувача:

    • username

    • email

    • password

    • confirm password

  • Сторінка /login/ містить форму входу користувача. Вона повинна отримувати введені дані від користувача:

    • username

    • password

  • Сторінки /create/ та /<article>/update/ містять форму для збору даних статті:

    • title

    • відповідні теми

    • content

  • Сторінка /<article>/delete містить просту форму для підтвердження видалення.

  • Форма зміни пароля має два поля:

    • new password

    • confirm password

  • Форма зміни даних користувача збирає всю інформацію, яка може бути змінена, наприклад, username, first name, last name та інше.

  • Сторінка налаштувань користувача містить список доступних тем. Користувач може відмітити деякі теми як пріоритетні (переваги). Також для пріоритетних тем стає доступною опція підписки на розсилку новинних листів.

Виклик: Slug-и статей

Попередження

Це додатковий виклик у додаток до:

  • Оновіть модель Article, додавши поле slug. Значення slug поля є:

    • обов’язкове для кожної статті

    • унікальне для кожної статті

  • Створіть міграцію даних для надання slug-ів існуючим статтям.

  • Поле slug повинно автоматично генеруватися при збереженні статті. Шаблон для генерації поля slug: назва-статті-дата-створення-статті, наприклад, стаття з назвою «Sample article», створена «24/03/2023», отримає slug: sample-article-2023-03-24.

  • Оновіть шлях URL для представлення деталей статті з динамічною частиною, якою буде slug статті.

Завдання: форми авторизації

  • Створити форму для реєстрації нових користувачів із обов’язковими полями:

    • username

    • email

    • password

    • confirm password

  • Значення username повинно перевірятися на відповідність існуючим значенням.

  • Значення password і confirm password мають збігатися.

  • Створити форму для входу існуючих користувачів.

  • Помилки перевірки повинні відображатися на шаблоні.

Завдання: Автентифікація

  • Для анонімних користувачів посилання /register/ і /login/ мають бути видимими на панелі навігації.

  • Для автентифікованих користувачів посилання /logout/ і /create/ мають бути видимими на панелі навігації.

  • Якщо автентифікований користувач є адміністратором або іншим, він має побачити посилання на сторінку адміністратора.

  • /register/: користувачі повинні надати всю необхідну інформацію про себе: бажане ім’я користувача та електронну адресу. Дані імені (ім’я та прізвище) необов’язкові. Після створення користувача вони повинні бути перенаправлені на сторінку входу для виконання процесу автентифікації. Недійсна форма повинна надавати інформацію про помилку(и).

  • /login/: користувачі повинні надати свої облікові дані для входу. У разі успішного входу вони повинні бути перенаправлені до свого профілю (якщо немає рядка запиту ?next=url).

  • /create/: Лише аутентифіковані користувачі повинні мати доступ до цієї сторінки. Якщо анонімний користувач намагається отримати доступ до цього представлення, його повинно перенаправити спочатку на сторінку входу, а після успішної аутентифікації повернути на сторінку створення статті. При створенні статті вона повинна мати автором поточного аутентифікованого користувача.

  • /<article>/comment/: У коментарі поточного аутентифікованого користувача повинна бути зазначена його ідентифікація як автора.

  • Змінювати або видаляти статті можуть тільки їх автори на сторінці деталей статті. Однак адміністратори все ще можуть виконувати дії зі статтями через адміністративну сторінку.

  • Шляхи, пов’язані з користувачем, обмежені для неаутентифікованих користувачів.

    • /set-password/

    • /set-userdata/

  • Запит POST на /deactivate/ повинен позначати поточного аутентифікованого користувача як видаленого і виходити з системи для цього користувача.

  • Авторизовані користувачі повинні мати можливість налаштовувати свої списки обраних тем.

  • Авторизовані користувачі повинні мати можливість підписатися або відписатися на обрану тему.

Попередження

Додаткові завдання

  • Призначте зміну порядку списку статей відповідно до вподобань аутентифікованого користувача. Для анонімних користувачів залиште типове сортування за замовчуванням.

  • Реалізуйте поведінку щодо відновлення облікового запису. Точний порядок дій не має значення. Один зі зразків сценаріїв може полягати у зборі електронної пошти користувача та перевірки наявності цієї адреси в базі даних. Після цього створіть запит для адміністратора на активацію облікового запису та надішліть підтверджувальний лист електронною поштою, коли все буде готово.

Виклик: Форми пов’язані зі статтями

  • Реалізуйте форму статті. Ця форма буде використовуватися для створення нових статей та оновлення існуючих.

  • Кожна створена стаття повинна мати принаймні одну пов’язану тему.

  • Реалізуйте форму коментаря, щоб збирати коментарі від користувача.

  • З даного моменту дозволені лише запити типу POST до /<article>/comment/.

  • Реалізуйте функціональність:

    • створення статті

    • оновлення статті

    • коментування статті (створення коментаря)

    • видалення статті

  • Лише аутентифіковані користувачі можуть створювати статі.

  • Стаття може редагуватись лише її автором.

  • Стаття може видалятись лише її автором.

  • Лише аутентифіковані користувачі можуть коментувати статті.

Завдання: Class-Based Views

  • Замінити всі існуючі перегляди через CBV.

  • Існуюча функціональність не повинна бути пошкоджена.

Примітка

Якщо потрібно, можна використовувати вбудовані класи відображення у Django (CBV).

Завдання: Серіалізатори

Тема статті

  • Серіалізатор для теми призначений лише для операцій читання (read-only). Теми можна створювати лише через адміністративну сторінку.

  • Серіалізовані дані повинні містити всю доступну інформацію, наприклад, pk, title, description.

Коментар до статті

  • серіалізатор коментаря статті може виконувати як операції читання, так і операції запису. Проте він не може використовуватися для оновлення або видалення коментаря.

  • Наразі можна використовувати випадкового або попередньо визначеного користувача як автора коментаря. Це буде виправлено у майбутньому.

Стаття

  • серіалізатор статей надає повний доступ до статей. Доступні всі операції: отримання списку, отримання окремої статті, створення нової статті, оновлення та видалення.

Користувач

  • Серіалізатор користувача надає повний доступ до даних користувачів сайту. Усі операції доступні наразі: отримання списку користувачів, отримання окремого користувача, створення нового користувача, оновлення та видалення. Однак, ця поведінка буде виправлена у майбутньому для запобігання несанкціонованим змінам даних.

Завдання: API views

Вся функціональність сайту повинна бути відображена за допомогою REST API.

Примітка

Наразі дозволяється передавати наперед визначеного користувача у тілі запиту. Це буде виправлено у наступному розділі.

Завдання: Автентифікація та Дозволи

  • Реалізуйте систему аутентифікації для REST API.

    • Для неаутентифікованих користувачів можлива створення нового облікового запису

    • Для неаутентифікованих користувачів можлива отримання даних аутентифікації.

  • Доступ до даних користувача обмежений. Авторизовані користувачі можуть маніпулювати лише своїми власними даними (наприклад, retrieve, update).

  • Адміністратори можуть отримати дані всіх користувачів (list), але не можуть змінювати їх через REST API. Однак це все ще можливо через адміністративну сторінку.

  • Авторизовані користувачі можуть create статті або update та delete статті, створені ними.

  • Авторизовані користувачі можуть додавати коментарі до вказаної статті.

  • Авторизовані користувачі можуть налаштовувати свої уподобання щодо тем.