1

Języki skryptowe – laboratorium

dr inż. Grzegorz Bazydło, mgr inż. Dawid Srokowski G.Bazydlo@iee.uz.zgora.pl, staff.uz.zgora.pl/gbazydlo

Lista zadań nr 5 Zagadnienia poznanie budowy i działania frameworka Django, tworzenie aplikacji webowej (moduł do zarządzania produktami w sklepie internetowym).

Framework Django

Dokumentacja Django znajduje się na stronie www.arturpyszczuk.pl/commands.html.

1. Tworzenie nowego projektu, aplikacji oraz uruchomienie serwera HTTP

Najprostszą metodą zarządzania kodem Django jest wykorzystywanie projektów. Jest to katalog zawierający z reguły pliki jednej witryny internetowej. Django jest dystrybuowane z plikiem django-admin.py, który w znaczny sposób ułatwia tworzenie takich katalogów. W przypadku systemów uniksowych plik ten powinien być umieszczony w katalogu /usr/bin, a w rodzinie systemów Windows – w podfolderze Scripts, w folderze instalacyjnym Pythona (np. C:\Python\Python35-32\Scripts). W obydwu przypadkach należy upewnić się, że ścieżka do pliku django-admin.py znajduje się w zmiennej systemowej PATH, aby istniała możliwość wywołania tego pliku z linii poleceń.

W celu utworzenia nowego projektu należy uruchomić konsolę i przejść do własnego katalogu (w lokalizacji C:\LABS) a następnie uruchomić polecenie:

django-admin startproject sklep

Parametr sklep to nazwa nowoutworzonego projektu. W wyniku powyższego polecenia zostanie utworzony nowy katalog, który powinien zawierać takie pliki jak:

manage.py – odpowiada za ogólne zarządzanie projektem. Tworzy ponadto nowe aplikacje, synchronizuje dane z bazami danych oraz pozwala na ich podgląd w języku SQL. Plik ten uruchamia także wbudowany w Django deweloperski serwer HTTP poprzez dodanie parametru runserver.

settings.py – jest to plik zawierający domyślne ustawienia projektu. Zalicza się do nich ustawienia baz danych, informacje przydatne w debugowaniu i inne ważne zmienne. Dowolna wartość z tego pliku jest dostępna we wszystkich aplikacjach z danego projektu.

urls.py – określany jest też mianem pliku URLconf. Jest to plik konfiguracyjny, który parsuje wzorce adresów URL i na ich podstawie podejmuje wybrane czynności. Pliki URLconf są niezwykłą i potężną siłą Django.

__init__.py – plik ten jest wymagany, aby zmusić Pythona do traktowania katalogów jako zawierające pakiety. Jest to konieczne, aby uchronić katalogi z powszechnie spotykanymi nazwami, takie jak "string", od niezamierzonego ukrycia poprawnych modułów, które pojawią się później na ścieżce poszukiwań modułów. W najprostszym przypadku, plik __init__.py może być pustym plikiem, ale może też zawierać pewien kod do wykonania.

Każdy utworzony w Django projekt posiada swoje aplikacje. To one odpowiadają za poszczególne funkcje

projektowanej witryny. W celu utworzenia nowej aplikacji należy posłużyć się plikiem manage.py, który znajduje się w nowo utworzonym katalogu (zanim wydasz polecenie wejdź do katalogu sklep):

manage.py startapp produkty

Powyższe polecenie tworzy nową aplikację o nazwie produkty – odpowiadającą za produkty w tworzonym sklepie internetowym. W ten sposób w katalogu projektu pojawił się nowy podkatalog produkty, zawierający pliki aplikacji:

models.py – definiuje wszystkie obiekty zwane modelami. Za pośrednictwem danych zawartych w tym pliku Django komunikuje się z bazą danych poprzez funkcję mapowania obiektowo-relacyjnego ORM. Dzięki temu można tworzyć rekordy w bazach danych bez znajomości języka SQL. Jest to niezwykle prosta i użyteczna metoda współpracy z bazami danych.

2

views.py – są to metody w Django, w których umieszczona zostaje część logiczna powstającej aplikacji. Plik ten ściśle współpracuje z informacjami zawartymi w modelu, które następnie przekazuje do szablonu wyświetlającego dane w przeglądarce.

__init__.py – spełnia tę samą funkcję co plik zawarty w katalogu głównym projektu.

W celu sprawdzenia poprawności konfiguracji można posłużyć się wbudowanym w Django serwerem WWW, który jest idealnym rozwiązaniem do testowania aplikacji w trakcie wdrażania. Do jego zalet można zaliczyć:

brak konieczności instalowania i konfiguracji serwera WWW, serwer automatycznie wykrywa zmiany w plikach źródłowych Pythona i natychmiastowo ładuje ponownie

moduły,

serwer wie, jak wyszukiwać i wyświetlać statyczne pliki multimedialne w aplikacji administratora.

Do uruchomienia serwera konieczne jest wykonanie jednego tylko polecenia. Wykorzystać do tego należy narzędzie manage.py:

manage.py runserver

Po uruchomieniu tego polecenia na konsoli powinny pojawić się informacje podobne do tych jak na rys. 1 (na razie nie przejmuj się komunikatem o niezatwierdzonych migracjach).

Rysunek 1

Uruchomiony serwer dostępny jest domyślnie pod adresem: http://127.0.0.1:8000. Wpisując ten adres w przeglądarkę, Django wyświetla stronę startową, informującą użytkownika o poprawnym pierwszym uruchomieniu projektu (rys. 2).

Rysunek 2

2. Utworzenie nowego modelu dla aplikacji produkty

Django, podobnie jak większość nowoczesnych frameworków sieciowych, wykorzystuje rozbudowaną warstwę dostępu do danych, która stanowi rodzaj pośrednika pomiędzy relacyjną bazą danych a aplikacjami tworzonymi w Pythonie. Zostało ono zaprojektowane z myślą o intensywnym wykorzystaniu mapowania ORM1.

Obiekty modeli w Django są zdecydowanie najlepszą metodą definiowania kolekcji pól, które zazwyczaj odpowiadają kolumnom w bazie danych. Dzięki temu realizować można pierwszą i zasadniczą czynność 1 ORM to skrótowe oznaczenie dla "mapowanie obiektowo-relacyjne" (ang. Object-Relational Mapping). Chodzi o zamianę danych w postaci tabelarycznej (relacji w bazie danych) na obiekty, albo w drugą stronę (źródło: elearning.pwste.edu.pl/blogjw/2-orm)

3

w odwzorowaniu relacyjnej bazy danych na składniki programowania obiektowego. Zamiast tworzyć zapytanie SQL, np. SELECT nazwisko FROM autorzy WHERE id=5, można zażądać obiektu Autor, którego ID ma wartość 5, a następnie sprawdzić pole autor.nazwisko.

Modele danych w Django obsługują wiele typów pól, a niektóre z nich są bardzo blisko związane z ich bazodanową implementacją. Istnieją jednakże typy, które zostały zaprojektowane z myślą o formularzach stron internetowych. Odwzorowaniem tabel SQL w Django są klasy Pythona, które reprezentują dane obiekty. Do najważniejszych klas należą:

CharField i TextField – są to prawdopodobnie najczęściej używane pola, wykorzystywanego do tego samego celu, czyli przechowywania tekstu. Pola typu CharField mają stałą, skończoną długość, zaś TextField mogą przechowywać teoretycznie nieskończenie wiele tekstu.

EmailField, URLField i IPAddressField – wszystkie te pola są w gruncie rzeczy polami CharField, jednak oferują one dodatkową walidację. W bazie danych są one przechowywane identycznie jak pole CharField, jednak dodatkowy kod zapewnia walidację, dzięki czemu można być pewnym, iż użytkownik wprowadził odpowiedni format danych jak adres e-mail, URL lub nr IP.

BooleanField i NullBooleanField – jest to odpowiedni wybór w większości sytuacji, gdy istnieje potrzeba przechowania wartości True lub False. Gdy wartość należy interpretować jako nieznaną (pustą), należy użyć klasy NullBooleanField.

FileField – jest jednym z najbardziej złożonych pól, ponieważ większość pracy nie jest związana z bazą danych, tylko z obsługą żądania. Pole to wyróżnia się możliwością wysłania pliku za pomocą przeglądarki użytkownika i przechowania go na serwerze. Udostępnia ono także metody odpowiedzialne za dostęp do wysłanego pliku za pomocą adresu URL.

W tworzonym sklepie internetowym zadeklarowane muszą zostać dane, które będą w sposób wystarczający

określać sprzedawany produkt. Dane, które obowiązkowo muszą zostać zdefiniowane to: nazwa produktu,

cena produktu,

dostępna ilość produktu,

data dodania produktu do oferty sklepu,

zdjęcie produktu.

W tym celu należy przejść do katalogu powstałej aplikacji produkty, a następnie uzupełnić plik models.py o definicje klasy Produkt (Listing 1).

# -*- coding: utf-8 -*-

from django.db import models

class Produkt (models.Model):

nazwa = models.CharField(max_length=150, verbose_name="Nazwa")

cena = models.DecimalField(max_digits=6, decimal_places=2, verbose_name="Cena")

ilosc = models.IntegerField(verbose_name="Ilość")

data = models.DateField(verbose_name="Data dodania")

grafika = models.FileField(upload_to="images/", verbose_name="Grafika")

def __unicode__(self):

return self.nazwa Listing 1

Pierwsza linia kodu informuje jaki system kodowania będzie wykorzystywany w danym modelu. Każdy nowo powstający model jest klasą dziedziczącą po django.db.models.Model, dlatego też zawsze należy na wstępie dodać linię:

from django.db import models

Kolejnym krokiem jest definicja klasy, w tym przypadku Produkt. Klasa ta posiada pięć pól, które będą przechowywały dane sprzedawanego produktu. Django automatycznie dodaje pole id oraz automatycznie stosuje nazewnictwo tabel w postaci nazwaaplikacji_model. Wartość verbose_name informuje nas, w jaki sposób będzie widoczne dane pole w bazie, natomiast upload_to wskazuje ścieżkę do katalogu, w którym będą zapisywane pliki ze zdjęciami sprzedawanych produktów. Ostatnie dwie linie służą do przekazania informacji dla systemu CMS o tym, jakie pole będzie wyświetlane na stronie definiującej dane produkty.

4

Aby możliwa była edycja produktów w systemie CMS, należy poinformować Django jakie modele mają się tam znajdować. W tym celu należy wyedytować plik admin.py, który może mieć strukturę jak na Listingu 2.

from django.contrib import admin

from produkty.models import Produkt

class ProduktAdmin(admin.ModelAdmin):

list_display = ('nazwa', 'cena', 'data', 'ilosc')

search_fields = ('nazwa', 'cena', 'data', 'ilosc')

date_hierarchy = 'data'

admin.site.register(Produkt) Listing 2

Na wstępie zostaje zaimportowany model Produkt, a następnie definiowana jest dla niego podklasa ProduktAdmin zawierająca pola, które będą wyświetlane w systemie CMS (list_display), przeszukiwane (search_files) oraz grupowane względem czasu (date_hierarchy). Końcowa linia rejestruje klasę Produkt w aplikacji Django Admin, służącej za swoisty CMS.

3. Konfiguracja projektu, połączenie z bazą danych oraz systemem CMS

W celu dodania zdefiniowanego modelu do bazy danych należy wyedytować plik konfiguracyjny settings.py, który znajduje się w katalogu projektu (sklep). Plik ten posiada najważniejsze informacje dot. całego projektu, takie jak parametry łączenia z bazą danych, obsługiwane aplikacje przez dany projekt, strefa czasowa, język itp.

Pierwszym krokiem jest dodanie nowo stworzonej aplikacji do INSTALLED_APPS:

INSTALLED_APPS = (

'django.contrib.admin',

'django.contrib.auth',

'django.contrib.contenttypes',

'django.contrib.sessions',

'django.contrib.messages',

'django.contrib.staticfiles',

'produkty',

)

Następnie należy zdefiniować bazę danych. Najprostszym sposobem jest praca z bazą SQLite3, która nie wymaga dodatkowej instalacji, a wystarczy jedynie utworzyć nowy plik o nazwie bazy (np. baza.db) z rozszerzeniem *.db i umieścić go w katalogu głównym projektu, a w pliku settings.py umieścić:

DATABASES = {

'default': {

'ENGINE': 'django.db.backends.sqlite3',

'NAME': os.path.join(BASE_DIR, 'baza.db'),

}

}

Pozostało jeszcze to zmiany pole LANGUAGE_CODE, którego zawartość zmieniamy na ‘pl-pl’, pole TIME_ZONE, które ustawiamy na ‘PL’ i określenie ścieżki, gdzie będą przechowywane pliki statyczne oraz zdjęcia produktów:

STATIC_URL = '/static/'

MEDIA_ROOT = os.path.join(BASE_DIR, 'media')

MEDIA_URL = '/media/'

Na tym etapie edycję pliku settings.py można zakończyć. Teraz należy wykonać migrację utworzonych modeli do bazy danych za pomocą dwóch poleceń:

manage.py makemigrations

manage.py migrate

Teraz uruchomienie serwera nie powinno już generować żadnych komunikatów o niezatwierdzonych migracjach.

Następnie należy utworzyć konto administratora (w Django jest to tzw. superuser) za pomocą polecenia:

manage.py createsuperuser

5

Należy podać nazwę użytkownika (np. admin), adres e-mail oraz hasło (minimum 8 znaków). Teraz uruchamiając serwer, powinniśmy mieć możliwość połączenia się z systemem Django Admin. W tym

celu należy wpisać adres http://127.0.0.1:8000/admin. Powinno ukazać się okno logowania, prosząc o podanie parametrów do logowania (superuser). Po

prawidłowym zalogowaniu użytkownik ma możliwość dodawania nowych produktów oraz zarządzania użytkownikami (rys. 3). Pliki zawierające obrazy będą zapisywane w nowoutworzonym katalogu media/images.

Rysunek 3

Jak widać mamy możliwość dodawania nowych produktów do bazy danych oraz ich edycji. Teraz korzystając z przycisków „Dodaj” oraz „Zmień” dodaj do bazy minimum 10 produktów. Utwórz też konto sprzedawca, który będzie miał prawa ograniczone tylko do zarządzania produktami (dodawanie, modyfikowanie i usuwanie).

4. Obsługa routingu

Mechanizmy łączące adres URL żądania i wygenerowaną odpowiedź stanowią sedno każdego frameworka aplikacji webowych. Django wykorzystuje prosty, ale funkcjonalny mechanizm, który pozwala na odwzorowanie opartych na wyrażeniach regularnych schematów adresów URL na pythonowe metody widoku. Istnieje możliwość łączenia ze sobą tych odwzorowań, umieszczając jedne w drugich. Taki system jest prosty w użyciu, a jednocześnie pozwala na niemal nieograniczone możliwości.

Tego typu odwzorowania są przechowywane w specjalnych plikach Pythona, nazywanych plikami URLconf. Każdy taki plik musi udostępniać obiekt urlpatterns, tworzony z reguły za pomocą funkcji patterns, zdefiniowanej w Django. Funkcja patterns przyjmuje następujące argumenty:

prefiks (łańcuch poprzedzający) – może być pusty,

jedna lub więcej krotek, z których każda zawiera: wyrażenie regularne dopasowujące jeden lub wiele adresów URL, funkcję widoku w postaci obiektu lub łańcucha znaków, a także słownik z argumentami dla tej funkcji.

Konfiguracji routingu dokonuje się w pliku urls.py. Plik ten tworzy się automatycznie podczas powstawania nowego projektu w katalogu z plikami głównymi – w naszym przypadku w katalogu /sklep/sklep. W jego domyślnej wartości zdefiniowane jest wyrażenie regularne określające ścieżkę do panelu administracyjnego, dzięki czemu możliwe było odwołanie się do strony za pośrednictwem adresu http://127.0.0.1:8000/admin.

Naszym zadaniem jest utworzenie odpowiedniej adresacji tak, aby możliwe było wyświetlanie pojedynczego produktu (np. o id=1) za pośrednictwem wywołania: http://127.0.0.1:8000/produkt/1 oraz wszystkich produktów na jednej stronie, wywołując adres: http://127.0.0.1:8000/produkt/wszystkie. Aby tego dokonać należy utworzyć dwupoziomową strukturę adresacji. W tym celu edytujemy najpierw plik urls.py w katalogu /sklep/sklep, dopisując do niego dodatkową linię:

(r'^produkt/',include('items.urls')),

Plik ten powinien mieć zawartość jak na Listingu 3.

6

from django.conf.urls import include, url

from django.conf.urls.static import static

from django.conf import settings

from django.contrib import admin

admin.autodiscover()

urlpatterns = [

url(r'^admin/', admin.site.urls),

url(r'^produkt/', include('produkty.urls')),

] + static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT) Listing 3

Jeśli użytkownik wprowadzi produkt w adresie, wówczas za pośrednictwem funkcji include() zostanie dołączony plik urls.py z wcześniej utworzonej aplikacji produkty. Ponadto dołączona została także ścieżka prowadząca do zmiennej MEDIA_URL, zawartej w pliku konfiguracyjnym settings.py w celu poprawnego wyświetlania wysyłanych przez CMS obrazów.

Idąc dalej należy przejść do katalogu /sklep/produkty i utworzyć nowy plik o nazwie urls.py. W pliku tym należy ustalić takie wyrażenia regularne, za pomocą których wywołany będzie widok listy wszystkich produktów, a także rekord posiadający określone ID – przypisane do konkretnego produktu. Plik ten powinien wyglądać jak na listingu nr 4.

from django.conf.urls import url

from produkty.views import pojedynczy, wszystkie

urlpatterns = [

url(r'^(?P<produkt_id>\d+)/$', pojedynczy, name='pojedynczy'),

url(r'^wszystkie/$', wszystkie, name='wszystkie'),

] Listing 4

W obu przypadkach po wywołaniu odpowiedniego wyrażenia regularnego zostanie załadowany plik z widokami (views.py) znajdujący się w aplikacji produkty. W pliku views.py w dalszej części instrukcji zostaną napisane funkcje, które pobiorą z bazy danych odpowiednio wszystkie rekordy odnoszące się do naszego produktu oraz pojedyncze, przypisane do konkretnego ID.

5. Tworzenie pliku widoku

Nieodłącznymi elementami współpracującymi z urls.py są pliki o nazwie views.py zwane widokami. Stanowią one podstawę każdej aplikacji Django, ponieważ dostarczają niemal całą logikę aplikacji. Widoki są funkcjami języka Python i to właśnie za jego pomocą należy projektować dane mechanizmy logiczne serwisu. Takie rozwiązanie daje niemalże nieograniczone możliwości programistyczne. Jedynym obowiązkiem projektanta widoków jest konieczność zapewnienia pobierania przez funkcję jednego parametru – obiektu HttpRequest – oraz zwracania obiektu typu HttpResponse.

Na potrzeby tworzonego sklepu internetowego konieczne jest napisanie prostego pliku widoku w aplikacji produkty. W tym celu edytujemy znajdujący się już tam plik views.py, dodając do niego kod jak na Listingu 5.

from django.shortcuts import render

from produkty.models import Produkt

from django.conf import settings

def pojedynczy(request, produkt_id):

return render(request, 'produkt.html', {'produkt' : Produkt.objects.get(id=

produkt_id), 'MEDIA_URL' : settings.MEDIA_URL})

def wszystkie(request):

return render(request, 'produkty.html', {'produkty' : Produkt.objects.all(),

'MEDIA_URL' : settings.MEDIA_URL }) Listing 5

Na wstępie importowana zostaje funkcja render(), odpowiadająca za renderowanie powstałych wyników dla

przeglądarek. Następnie konieczne jest zaimportowanie klasy Produkt (zdefiniowanej w pliku models.py). Na

7

widok składają się dwie funkcje. Pierwsza z nich pobiera pojedynczy rekord modelu Produkt o id=produkt_id, a następnie dla tego obiektu zapisuje zawartość w zmiennej ‘produkt’, po czym wartość ta jest renderowana do pliku szablonu o nazwie produkt.html. Druga funkcja działa podobnie z tym, że pobiera wszystkie rekordy modelu Produkt, po czym zapisuje je w zmiennej ‘produkty’, a następnie renderuje do pliku produkty.html.

6. Szablony

Szablony są niezależnymi plikami tekstowymi, zawierającymi treść statyczną oraz dynamiczne znaczniki określające m.in. działanie logiki, pętle i sposób wyświetlania danych. Wybór szablonu zastosowanego do renderowania strony jest podejmowany w funkcji widoku lub w jej argumentach. Język szablonów został zaprojektowany z myślą o projektantach interfejsu, którzy nie muszą być programistami. Z tego względu (a także w celu odseparowania logiki od prezentacji) język szablonów nie został zagnieżdżony w Pythonie. Mimo to twórcy interfejsu mogą korzystać z licznych znaczników i filtrów, aby zastosować bardziej zaawansowane konstrukcje, wykorzystywane do generowania kodu HTML.

Szablony będące dynamicznymi dokumentami tekstowymi nie byłyby użyteczne, gdyby nie oferowały możliwości wyświetlania dynamicznych danych, zależnych od różnorodnych źródeł informacji. W Django z tym właśnie procesem jest nierozerwalnie związany obiekt przekazywany z widoku do szablonu, czyli tzw. kontekst. Kontekst szablonu to z reguły słownik zawierający pary klucz-wartość, reprezentowany przy użyciu słownikopodobnego obiektu Context. W przypadku wykorzystania widoków generycznych jest on wypełniany automatycznie, natomiast w widokach własnych przekazywany jest w wywołaniu metody render() należącej do szablonów lub przy użyciu funkcji render_to_response().

Podobnie jak w przypadku większości języków szablonów i Django oferuje różnego rodzaju pojedyncze polecenia – takie jak wyświetlanie wartości zmiennej, czy też instrukcje złożone, blokowe, do których zaliczyć można np. if i for. Język szablonów Django udostępnia dwie konwencje zapisu takich instrukcji z wykorzystaniem nawiasów klamrowych. Aby wypisać wartość zmiennej, wystarczy skorzystać z zapisu {{zmienna}}. Wszystkie pozostałe operacje są wykorzystywane przy użyciu znaczników {% polecenie %}.

Aby rozpocząć pracę z szablonami konieczne jest poinformowanie Django o tym jak wygląda struktura katalogów, w których będą przechowywane pliki szablonów. W związku z tym należy przejść do pliku settings.py i dodać do niego ścieżkę dostępu do katalogów, np.:

TEMPLATES = [

{

…

'DIRS': ['produkty/templates/', 'templates/',],

…

},

]

Należy w wyżej wskazanych miejscach utworzyć dwa katalogi z szablonami. Pierwszy – główny, w którym będzie przechowywany plik main.html, oraz drugi zagnieżdżony w aplikacji produkty.

Gdy Django ma już zdefiniowane katalogi przechowywania szablonów, należy w nich utworzyć odpowiednie pliki. Tak więc w pierwszym katalogu tworzymy nowy plik o nazwie main.html. Plik ten będzie naszym głównym szablonem, w którego zawartości będziemy zagnieżdżać inne szablony (z katalogu produkty), dzięki czemu tylko dynamiczne elementy strony będą się ładowały podczas przechodzenia pomiędzy podstronami, co znacznie wpłynie szybkość wczytywania stron. Budowa pliku main.html jest typowa dla plików HTML, różnicę jedynie stanowić będzie fragment, w którym poinformujemy gdzie ma być wczytywana zawartość z aplikacji produkty, czyli informacje o produktach. W najprostszej formie może to wyglądać jak na listingu 6.

<!DOCTYPE html>

<html>

<head>

<title>Django - sklep internetowy</title>

<meta content="Django - sklep internetowy">

<meta content="django, sklep" name="keywords">

<meta content="text/html; charset=utf-8" http-equiv="content-type">

<meta content="pl" http-equiv="content-language">

</head>

<body>

{% block content %}

{% endblock %}

8

</body>

</html> Listing 6

Jak można się domyślić znacznik {% block content %} informuje, gdzie rozpoczyna się blok wczytywany z innego szablonu (blok o nazwie content), zaś {% endblock %} to znacznik kończący dany blok.

Kolejnym krokiem jest utworzenie drugiego szablonu w aplikacji produkty. Przechodzimy więc do katalogu produkty/templates, gdzie tworzymy plik produkty.html. W tym pliku będzie przeważał język szablonów, który dzięki wykorzystaniu pętli for będzie wyświetlał wszystkie informacje o danym produkcie, tj. nazwę, cenę, ilość, datę dodania oraz zdjęcie (Listing 7).

{% extends "main.html" %}

{% load static %}

{% block content %}

{% for produkt in produkty %}

<p>Nazwa produktu: {{ produkt.nazwa }}</p>

<p>Cena: {{ produkt.cena}} zł </p>

<p>Ilość: {{ produkt.ilosc}}</p>

<p>Data dodania: {{ produkt.data}}</p>

<p><img src="{{ MEDIA_URL }}{{ produkt.grafika }}" height="213px" width="150px"/></p>

<hr>

{% endfor %}

{% endblock %} Listing 7

Pierwsza linia informuje o tym jaki plik jest głównym szablonem, kolejna rozpoczyna dany blok, po czym przechodzimy do prostej pętli. Pobiera ona wszystkie elementy ze zmiennej produkty, które wcześniej zdefiniowaliśmy w modelu, czyli produkt.nazwa, produkt.cena, produkt.ilosc, produkt.data. Następnie ze zmiennej MEDIA_URL zdefiniowanej w pliku settings.py pobierany jest adres, gdzie przechowywane są pliki z obrazami, po czym dołączona zostaje właściwa nazwa pliku do wyświetlenia. Istotnym jest, aby pamiętać o zakończeniu pracy pętli oraz całego bloku znacznikami widocznymi na samym dole kodu.

Prawidłowe działanie utworzonych szablonów powinno wyświetlić wszystkie dodane za pośrednictwem systemu CMS produkty jak na rys. 4.

Rysunek 4

9

Pozostała jeszcze kwestia wyświetlania pojedynczych artykułów. Zgodnie z tym, co zostało napisane w pliku widoków – należy utworzyć kolejny szablon o nazwie produkt.html. Będzie się on znajdował w katalogu szablonów aplikacji produkty. Jego zawartość będzie niemal identyczna do szablony produkty.html, z tym że pominięta zostanie pętla for (Listing 8).

{% extends "main.html" %}

{% load static %}

{% block content %}

<p>Nazwa produktu: {{ produkt.nazwa }}</p>

<p>Cena: {{ produkt.cena}} zł </p>

<p>Ilość: {{ produkt.ilosc}}</p>

<p>Data dodania: {{ produkt.data}}</p>

<p><img src="{{ MEDIA_URL }}{{ produkt.grafika }}" height="213px" width="150px"/></p>

<hr>

{% endblock %} Listing 8

W ten sposób po wpisaniu adresu dotyczącego pojedynczego produktu, powinna ukazać się strona zawierająca informacje o danym produkcie (rys. 5).

Rysunek 5

7. Podsumowanie

Realizując wszystkie z opisanych powyżej kroków powinna zostać zbudowana aplikacja WWW, która dynamicznie pobiera informacje z bazy danych i wyświetlała je na stronie. Szablony można wzbogacić w style CSS, dzięki czemu strona nabierze atrakcyjniejszego wyglądu. Ponadto wskazanym byłoby zrobienie przekierowania z głównej strony wyświetlającej wszystkie produkty, do strony dedykowanej dla konkretnego produktu, np. poprzez kliknięcie w nazwę produktu. Ponadto sam model produktu można wzbogacić także o inne pola, jak np. opis, które będą wyświetlane tylko na stronie dedykowanej dla produktu.