Autor: programista

We wcześniejszych wpisach opisałem zarządzanie użytkownikami w >>aplikacji<< tzn. nowy użytkownik może się zarejestrować – utworzyć konto w witrynie, użytkownik zarejestrowany może się zalogować, wylogować lub zmienić swoje hasło.

Następnie opiszę główną funkcjonalność witryny tzn. ewidencję aut i napraw. W tym celu w pliku urls.py projektu załączę mapowanie adresów związanych z aplikacją cars. Po zmianach plik urls.py projektu będzie wyglądał następująco:

from django.contrib import admin
from django.urls import path, include
from users import views as users_views
from django.contrib.auth import views as auth_views

urlpatterns = [
    path('admin/', admin.site.urls),
    path('', include('cars.urls')),
    path('register-user/', users_views.RegisterUser.as_view(
        template_name='users/register-user.html'), name='register_user'),
    path('login/', auth_views.LoginView.as_view(template_name='users/login.html'), name='login'),
    path('logout/', auth_views.LogoutView.as_view(template_name='users/logout.html'), name='logout'),
    path('change-password/', users_views.ChangePassword.as_view(
        template_name='users/change-password.html'), name='change_password'),
]

Można zauważyć, że mapowanie adresów na odpowiednie widoki uwzględnia też plik urls.py utworzony w aplikacji cars. Plik urls.py z aplikacji cars wyglada następująco:

from django.urls import path
from .views import (
    CarsListView,
    AddCarView,
    RepairsListView,
    UpdateCarView,
    DeleteCarView,
    AddRepairView
)
urlpatterns = [
    path('', CarsListView.as_view(), name='cars'),
    path('add-car/', AddCarView.as_view(), name='add_car'),
    path('car/', RepairsListView.as_view(), name='car_detail'),
    path('car/<int:pk>/update/', UpdateCarView.as_view(), name='update_car'),
    path('car/<int:pk>/delete/', DeleteCarView.as_view(), name='delete_car'),
    path('car/<int:pk>/new-repair/', AddRepairView.as_view(), name='add_repair'),
]

Główny widok definiowany w klasie CarListView wyświetla wszystkie auta użytkownika.

Należy pamiętać o dopisaniu aplikacji w pliku settings.py projektu w liście INSTALLED_APPS np. dla aplikacji cars będzie to element: ‘cars.apps.CarsConfig’.

W aplikacji users korzystałem z preinstalowanego modelu użytkownika. W aplikacji cars należy stworzyć modele – obiekty mapujące tabele bazy danych. Modele te będą definiować: pojazd – model Car i naprawę – model Repair. Kod pliku models.py aplikacji cars wygląda następująco:

from django.db import models
from django.contrib.auth.models import User
from django.utils import timezone
from django.core.validators import MaxValueValidator, MinValueValidator


class Car(models.Model):
    make = models.CharField(max_length=10)
    model = models.CharField(max_length=10)
    vrn = models.CharField(max_length=10)
    year = models.IntegerField(default=timezone.now().year,
                               validators=[MinValueValidator(timezone.now().year - 100),
                                           MaxValueValidator(timezone.now().year)])
    user = models.ForeignKey(User, on_delete=models.CASCADE)

    def __str__(self):
        return f'{self.make} {self.model}'


class Repair(models.Model):
    date = models.DateField(default=timezone.now)
    description = models.TextField()
    car = models.ForeignKey(Car, on_delete=models.CASCADE)

    def __str__(self):
        lead = self.description[:10] + '...'
        return lead

Model Car zawiera atrybuty make, model, vrn, year i user opisujące markę pojazdu, model, nr rejestracyjny pojazdu i rok produkcji, a także klucz obcy, zawierający obiekt użytkownika, który utworzył wpis o pojeździe. Pole year posiada walidatory, uniemożliwiające wpisanie auta o roku produkcji o 100 lat starszym od bieżącej daty i nowszym niż bieżący rok. Opcja on_delete atrybutu user ma wartość domyślną CASCADE tzn. usunięcie użytkownika, który wprowadzić powoduje także usunięcie wszystkich wprowadzonych przez niego aut.

Model Repair zawiera atrybuty date – data naprawy, description – szczegóły naprawy oraz car, będący kluczem obcym – jakiego auta dotyczy dana naprawa. Metoda __str__() wyświetla nagłówek będący początkiem opisu naprawy (10 początkowych znaków).

Aby móc dokonywać edycji wpisów obu modeli z poziomu panelu administracyjnego trzeba dopisać oba modele do pliku admin.py aplikacji cars tzn.

from django.contrib import admin
from .models import Car, Repair

admin.site.register(Car)
admin.site.register(Repair)

W następnej części opiszę widoki definiujące poszczególne funkcjonalności tzn. wyświetlanie aut należących do użytkownika, dodawanie napraw, a także wyszukiwanie aut za pomocą pola wyszukiwania na stronie.

— c. d. n. —

We >>wstępie<< opisałem główne założenia projektu.

Poniżej zamieszczam listing wymaganych pakietów do projektu (wygenerowany przez pip freeze):

asgiref==3.2.5
Django==3.0.4
django-crispy-forms==1.9.0
pytz==2019.3
sqlparse==0.3.1

Polecam utworzyć osobne środowisko wirtualne dla projektu (jak stworzyć wirtualne środowisko opisałem >>tutaj<<).

Wszystkie pakiety oprócz django-crispy-forms instalowane są podczas instalacji pakietu django.

W katalogu zawierającym również podkatalog venv tworzymy projekt za pomocą komendy: django-admin startproject nazwa_projektu

Startproject tworzy główny katalog projektu oraz plik manage.py, dzięki któremu można będzie zarządzać projektem.

Następnie można utworzyć administratora projektu, czyli użytkownika o maksymalnych uprawnieniach administracyjnych, dzięki czemu będzie można używać webowego panelu administracyjnego. Jednak najpierw należy przeprowadzić migracje: python manage.py migrate dzięki czemu zostają utworzone odpowiednie tabele w bazie danych np. admin, auth itd. Po przeprowadzonej migracji można utworzyć konto administracyjne za pomocą komendy: python manage.py createsuperuser

Katalog projektu zawiera następujące pliki i katalogi:
├── nazwa_projektu
│   ├── asgi.py
│   ├── init.py
│   ├── pycache
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
├── db.sqlite3
└── manage.py

Domyślnie dane umieszczane zostają w bazie sqlite3 (standardowo plik db.sqlite3), co jest dobrym rozwiązaniem podczas tworzenia projektu, a finalnie można użyć innej bazy (Django zawiera wsparcie dla PostgreSQL, MySQL i wielu innych). Zmiana domyślnej bazy wymaga tylko modyfikacji danych z sekcji DATABASES pliku settings.py projektu.

Aby odseparować poszczególne elementy składowe projektu wydzieliłem dwie części składowe tzn. odpowiedzialną za zarządzanie użytkownikami – users oraz za zarządzanie pojazdami – cars. W Django są to tzw. aplikacje. Aby je utworzyć należy wpisać: python manage.py startapp users oraz python manage.py startapp cars

Zacznę od aplikacji users, w której nowi użytkownicy będą mogli tworzyć konta, oraz logować się, wylogowywać, a także zmieniać swoje hasło dostępowe.

Aby określić mapowanie adresów URL na konkretne klasy widoków modyfikuję plik urls.py projektu tzn.

from django.contrib import admin
from django.urls import path
from users import views as users_views
from django.contrib.auth import views as auth_views

urlpatterns = [
    path('admin/', admin.site.urls),
    path('register-user/', users_views.RegisterUser.as_view(
        template_name='users/register-user.html'), name='register_user'),
    path('login/', auth_views.LoginView.as_view(template_name='users/login.html'), name='login'),
    path('logout/', auth_views.LogoutView.as_view(template_name='users/logout.html'), name='logout'),
    path('change-password/', users_views.ChangePassword.as_view(
        template_name='users/change-password.html'), name='change_password'),
]

Przykładowo po wpisaniu adresu kończącego się na: register-user/ zostaje wywołana klasa RegisterUser() z pliku views.py oraz do tego przypisania zostaje nadana nazwa, której będziemy mogli używać w szablonach. Aby klasa mogła być użyta jako widok, należy wywołać jej metodę as_view(). Jako argument podałem argument template_name, w którym podaję nazwę szablonu, który wyświetla podaną stronę. Równie dobrze można by podać ten argument jako atrybut klasy w widoku, ale aby zachować spójność z pozostałymi widokami umieściłem go w tym miejscu.

kod klasy RegisterUser() z pliku views.py aplikacji users wygląda następująco (na początku umieściłem wymagane importy)

from django.shortcuts import render, redirect
from django.contrib.auth.forms import UserCreationForm, PasswordChangeForm
from django.contrib.auth import login, authenticate
from django.views.generic import CreateView
from django.contrib import messages

class RegisterUser(CreateView):
    form_class = UserCreationForm

    def get(self, request, *args, **kwargs):
        return render(request, 'users/register-user.html', {'form': UserCreationForm()})

    def post(self, request, *args, **kwargs):
        form = UserCreationForm(request.POST)
        if form.is_valid():
            form.save()
            username = form.cleaned_data.get('username')
            password = form.cleaned_data.get('password1')
            user = authenticate(username=username, password=password)
            login(request, user)
            messages.success(request, f'Welcome, {username}!')
            return redirect('cars')
        return render(request, 'users/register-user.html', {'form': form})

Klasa RegisterUser() dziedziczy po klasie CreateView, a formularz jest definiowany przez klasę UserCreationForm. Gdy strona zostaje wyświetlona za pomocą metody GET to pojawia się pusty formularz, gdy natomiast podane są już jakieś dane w formularzu, to są one przekazane za pomocą metody POST. Aby obsłużyć GET i POST przesłaniam odpowiednio metody get() i post() klasy RegisterUser(). W metodzie post() sprawdzana jest poprawność formularza i jeśli formularz jest poprawny to następuje zapisanie danych z formularza tzn. utworzenie użytkownika za pomocą metody save(). Domyślnie jest to użytkownik pozbawiony przywilejów administracyjnych. Zostaje on zalogowany przy użyciu podanych przy rejestracji danych. Nowa wiadomość z tagiem Success zostanie wyświetlona po przekierowaniu na adres o nazwie cars. Wiadomość wyświetla się tylko jednokrotnie na stronie.

Pozostaje jeszcze utworzyć szablon register-user.html dla RegisterUser(). W tym celu tworzę katalog szablonów w aplikacji users zgodnie z konwencją – w katalogu templates należy utworzyć kolejny katalog z nazwą zgodną z nazwą aplikacji tzn.

nazwa_projektu/users/templates/users/register-user.html

Kod pliku register-user.html jest częścią większej całości, a ściślej nie utworzonego na razie pliku base.html z aplikacji cars. Aplikacje mogą korzystać ze swoich szablonów, a dzięki temu wygląd zdefiniowany w aplikacji cars w szablonie base.html jest zachowany w szablonie register-user. W szablonie jest też włączone korzystanie z tagów crispy_forms, dzięki którym formularz wygląda lepiej. Każdy formularz musi zawierać csrf_token, dzięki czemu strona jest automatycznie odporna na pewne formy ataków (szczegóły >>tutaj<<).

Listing pliku register-user.html wygląda następująco:

{% extends 'cars/base.html' %}
{% load crispy_forms_tags %}

{% block content %}
  <div class="row justify-content-center">
    <div class="col-4">
      <form method="POST" class="form-control-sm">
        {% csrf_token %}
        <fieldset class="form-group">
          <legend class="border-bottom text-primary">
            Registration
          </legend>
            {{ form|crispy }}
        </fieldset>
          <button class="btn btn-secondary" type="submit">Register</button>
      </form>
    </div>
  </div>
{% endblock %}

>>część 2<<