Модуль 17

Generic views та їх використання

Ось твій урок у стилі CS50. Вмикай проектор, бери каву — поїхали! 🚀

🎓 CS50: Generic Views (Дженеріки) — Мистецтво не робити зайвого

Вітаю, друзі!

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

Саме так. Програмісти — це, мабуть, найлінивіші люди у світі. Але в хорошому сенсі! Ми ненавидимо рутину. Ми ненавидимо писати код, який ми вже писали вчора.

Сьогодні ми поговоримо про те, як перестати бути «друкарською машинкою» і почати бути архітектором. Тема уроку: Generic Views (або просто «Дженеріки»).

1. 🔥 Вступ: Дежавю вашого коду

Уявіть, що ви відкриваєте мережу піцерій. У вас є піцерія в Києві, у Львові та в Одесі.

Якби ви працювали без стандартів, то в Києві кухар різав би тісто квадратами, у Львові — трикутниками, а в Одесі взагалі робив би тільки чебуреки. І для кожного міста вам довелося б писати окрему інструкцію з нуля.

Але ж процес приготування піци (CRUD) майже скрізь однаковий: 1. Взяти замовлення (Create) 2. Показати меню (Read / List) 3. Змінити інгредієнти (Update) 4. Викинути згорілу піцу (Delete)

У веб-розробці (особливо в Django) ми постійно робимо те саме: * Вивести список статей. * Показати одну статтю. * Створити статтю.

Питання до вас: Навіщо нам щоразу писати функцію, яка робить запит до бази даних, завантажує шаблон і віддає HTML, якщо 90% цього коду ідентичні?

Без Generic Views ви приречені на вічне "Copy-Paste". А з ними — ви пишете лише те, що робить вашу піцу унікальною.

2. 🧠 Теоретична база: Що там «під капотом»?

Давайте розберемося без складних термінів.

Generic View (Узагальнене представлення) — це готовий клас (шаблон коду), який вже знає, як виконувати стандартні дії веб-сайту. Це як напівфабрикат вищого гатунку: тісто вже розкатане, соус намазаний, вам треба лише кинути зверху свої улюблені оливки.

Як це працює? (Логіка, а не синтаксис)

У звичайному підході (Function Based View) ви кажете програмі ЯК щось зробити:

"Піди в базу, візьми всі об'єкти моделі Post, поклади їх у змінну context, візьми шаблон 'post_list.html', відрендери це все..."

У Generic Views ви кажете програмі ЩО ви хочете отримати:

"Я хочу список (ListView). Модель — Post. Шаблон — стандартний."

Все інше дженерік робить сам.

🔑 Три кити, які треба запам'ятати:

  1. ListView — для відображення списку об'єктів (каталог товарів, стрічка новин).
  2. DetailView — для відображення однієї сторінки (сторінка товару, повний текст статті).
  3. FormView / CreateView / UpdateView — для роботи з формами (реєстрація, додавання коментаря).

Інтуїтивно: Це як конструктор LEGO. Є деталька "колесо". Вам не треба виплавляти гуму і пластик. Ви просто берете "колесо" і ставите на свою "машинку".

3. 🧪 Приклади: Від болю до елегантності

Давайте подивимось на код. Я буду використовувати Django як приклад, бо тут це реалізовано найяскравіше.

Приклад 1: Старий добрий (і довгий) спосіб

Уявіть, що ми робимо блог. Ось як ми писали раніше:

# views.py (Function Based View)
from django.shortcuts import render
from .models import Post

def post_list(request):
    # 1. Йдемо в базу
    posts = Post.objects.all()
    # 2. Готуємо контекст
    context = {'posts': posts}
    # 3. Рендеримо шаблон
    return render(request, 'blog/post_list.html', context)

Ніби не складно, так? Але уявіть, що у вас 50 моделей. Ви напишете цей код 50 разів.

Приклад 2: Магія Generic Views 🎩

А тепер дивіться сюди. Те саме, але на класах:

# views.py (Class Based Generic View)
from django.views.generic import ListView
from .models import Post

class PostListView(ListView):
    model = Post
    template_name = 'blog/post_list.html'  # (навіть це можна не писати, якщо назвати файл правильно)
    context_object_name = 'posts'

Що ви очікуєте побачити? Результат буде ідентичним. Користувач не побачить різниці. Але ми написали менше логіки. Ми просто налаштували клас.

Приклад 3: Реальна ситуація (Трохи складніше)

А якщо нам треба не просто всі пости, а тільки опубліковані? І впорядковані за датою?

У функції ви б дописували filter() і order_by(). У дженеріку ми просто перевизначаємо метод get_queryset.

class PostListView(ListView):
    model = Post
    template_name = 'blog/post_list.html'
    context_object_name = 'posts'

    # Перевизначаємо логіку отримання даних
    def get_queryset(self):
        return Post.objects.filter(is_published=True).order_by('-created_at')

Чому це круто? Тому що логіка вибірки даних ізольована. Ви чітко бачите: тут налаштування (змінні класу), а тут — логіка (метод).

4. 🛠 Практична частина

Час розім'яти пальці! Відкривайте IDE (або уявіть, що відкрили).

Завдання 1: Рефакторинг У вас є функція view_all_books, яка виводить список книг. Перепишіть її, використовуючи ListView.

Завдання 2: Деталі Створіть BookDetailView, використовуючи дженерік DetailView. Він має показувати інформацію про одну конкретну книгу за її ID (pk). Підказка: Вам навіть не треба писати код для пошуку в базі, DetailView сам знайде об'єкт за ID з URL-адреси.

Завдання 3: "А що, якщо..." (Виправляємо помилку) Ви створили ListView, вказали model = Car, але забули вказати template_name. Django видасть помилку TemplateDoesNotExist. Питання: Яке ім'я шаблону Django очікує за замовчуванням? (Спробуйте здогадатися за логікою: <app_label>/<model_name>_list.html).

Завдання 4: Міні-кейс Вам потрібно створити сторінку додавання нового коментаря. Використайте CreateView. Вам знадобляться поля: model, fields (список полів форми) та success_url (куди перенаправити після успіху).

Завдання 5: Челендж Зробіть так, щоб ваш ListView показував лише ті книги, у яких в назві є слово "Python". Підказка: Погугліть self.request.GET.get('q') всередині методу get_queryset.

5. 💡 Мислення як у розробника

Як відрізнити новачка від профі, дивлячись на використання Generic Views?

❌ Помилка новачка: "Натягування сови на глобус"

Новачки іноді так люблять дженеріки, що намагаються використовувати їх там, де логіка надто складна. Якщо вам доводиться перевизначати 10 методів у ListView, щоб він працював як треба — зупиніться. Напишіть звичайну функцію. Generic Views ідеальні для стандартних задач. Для нестандартних вони стають пеклом.

✅ Думка профі:

"Чи можу я описати цю сторінку словами 'Просто список об'єктів' або 'Просто форма створення'?" * Якщо ТАК — беру Generic. * Якщо НІ (наприклад, треба відправити три емейли, оновити дві різні моделі і викликати API) — пишу View вручну.

🚀 Порада з практики:

Завжди заглядайте у вихідний код дженеріків (або використовуйте сайт ccbv.co.uk — це "біблія" для Django Class Based Views). Ви маєте розуміти, які методи викликаються ланцюжком, щоб знати, в яке місце "вклинитися" зі своєю логікою.

6. 🧩 Підсумок

Отже, що ми сьогодні зрозуміли?

  1. Generic Views — це інструмент для боротьби з рутиною. Ми не пишемо код для стандартних дій.
  2. Ми використовуємо ListView для списків, DetailView для сторінок об'єктів, Create/UpdateView для форм.
  3. Ми навчилися думати абстракціями: налаштовувати класи, а не писати процедурний код крок за кроком.

Що ви тепер вмієте? Ви можете створити повноцінний CRUD (Create, Read, Update, Delete) функціонал для сайту в 4-5 разів швидше, ніж раніше.

Що далі? Ви запитаєте: "Дейвіде, а як заборонити видаляти пости всім підряд? Як пускати тільки адміна?" Чудове питання! На наступному уроці ми розберемо Mixins та Декоратори. Це як фейс-контроль для ваших Views.

А поки що — це був CS50. Дякую за увагу! 👋

← До списку уроків Наступний урок →