Ładowanie
Załóżmy, że otrzymaliśmy zlecenie na stworzenie sklepu internetowego od ważnego, ale wybrednego klienta. Ponieważ projekt ma pozwalać na dowolną rozbudowę i modyfikację w przyszłości, zdecydowaliśmy się nie korzystać z gotowych rozwiązań. Nie chcemy też utrudniać sobie życia, wiążąc się z mniej elastycznymi środowiskami pracy, a z drugiej strony zależy nam na wykonaniu podstawowej, funkcjonalnej wersji witryny w czasie niewiele dłuższym od tego, którego potrzebowalibyśmy na konfigurację gotowego skryptu. Z czego więc skorzystamy? Oczywiście z Django!
Zaprezentowana w artykule aplikacja jest rozwiązaniem uproszczonym, pozbawionym wielu przydatnych elementów – w zupełności jednak wystarczy, by pokazać w praktyce zalety pracy z Django. Co ważne, aby zacząć przygodę z programowaniem w środowisku pythonowego frameworka nie trzeba być ekspertem – wystarczy w zasadzie znajomość podstaw HTML i Pythona, choć i inny język dynamiczny (np. PHP 5) powinien także wystarczyć. Całość kodu źródłowego znajduje się w dołączonym pliku ZIP.
Podstawowe założenia projektu
Nasz klient chciałby w pierwszej wersji uwzględnić podstawowe funkcjonalności – gotowe do edycji strony statyczne (strona główna, informacje dotyczące firmy itp.) oraz możliwość samodzielnego dodawania produktów z ceną, opisem i zdjęciem. Do tego przydatne będzie również zastosowanie podziału wszystkich oferowanych towarów na kategorie oraz obsługa koszyka i formularza zamówienia, wraz z opcją wysłania szczegółów zlecenia na adres e-mail. Obok tych kilku wskazówek otrzymamy na wstępie także przygotowany przez grafika szablon HTML z CSS. I tutaj zaczyna się nasza praca – z Django.
Przygotowanie środowiska
Aby rozpocząć projektowanie aplikacji, musimy oczywiście zadbać najpierw o samo środowisko pracy. Jak już wspominaliśmy w naszym wprowadzeniu, nie jest ono szczególnie skomplikowane. Na początek wystarczy nam instalacja Pythona w wersji 2.5 lub 2.6, Django w wersji 1.0 oraz Biblioteki PIL, wspierającej obróbkę obrazów. W tym ostatnim wypadku należy wybrać wersję o numerze odpowiadającym wersji zainstalowanego Pythona (Windows) lub po prostu użyć instalatora pakietów systemowych (Linux).
Czy konieczny jest serwer Apache lub baza danych MySQL? |
|---|
| Aby przygotować aplikację w Django, nie musimy instalować obu wymienionych elementów. Python potrafi symulować serwer WWW, a w wersji 2.5 zawiera także wbudowany system bazodanowy SQLite. Apache lub MySQL będą nam potrzebne dopiero przy produkcyjnym wdrożeniu witryny. |
Po pomyślnym przeprowadzeniu instalacji utwórzmy folder koszulki, w którym znajdzie się cały przykładowy projekt.
Wygląd strony – pierwsze szablony
Jak już wspomnieliśmy na wstępie, klient dostarczył nam przygotowany wcześniej szablon strony. Dysponując kodem HTML, rozbijmy go więc na część wspólną, stałą (nagłówek, stopka, itp.) i część zmienną. Django pozwala korzystać z systemu dziedziczenia, w którym to szablony szczegółowe określają, co powinno znaleźć się w szablonie ogólnym, we wcześniej ustalonych miejscach. Te ostatnie określane są za pomocą znaczników {% block %}. Nasz szablon ogólny ma więc następującą postać:
| <html> <head> <title>Sklepik z koszulkami</title> <link rel="stylesheet" type="text/css" href="{{ MEDIA_URL }}main.css" /> </head> <body> <div id="content"> <h1>Sklepik z koszulkami</h1> <div id="basket"><a href="/sklep/koszyk/">Koszyk (0)</a></div> <div id="menu"><a href="/">Strona główna</a> | <a href="sklep/produkty/">Produkty</a></div> <div id="main"> {% block main_box %}{% endblock %} </div> <div id="footer"><a href="/o-firmie/">O firmie</a></div> </div> </body> </html> |
| Listing 1 – Szablon ogólny |
Jak widać, poszczególne bloki mają identyfikatory (np. main_box) i mogą zawierać domyślną treść, która będzie użyta, jeśli szablon szczegółowy jej nie zmieni. Element {{ MEDIA_URL }} zostanie w trakcie renderowania zastąpiony adresem URL folderu z plikami statycznymi. Szablony szczegółowe będziemy tworzyli w miarę potrzeb, przejdźmy więc teraz od razu do generowania szkieletu projektu.
Projekt, panel administracyjny i strony statyczne
W utworzonym wcześniej folderze koszulki powinniśmy wykonać z poziomu powłoki polecenie: django-admin startproject sklepik. Dzięki temu utworzymy nowy projekt wraz z kilkoma niezbędnymi plikami. Jeśli przyjrzymy się strukturze katalogów, zobaczymy między innymi folder sklepik. Musimy w nim utworzyć trzy kolejne zbiory: templates, templates/flatpages oraz webroot. Następnie w katalogu templates umieszczamy plik base.html, o treści przedstawionej na listingu nr 1. Podstawowy arkusz stylów main.css (dostępny w archiwum z przykładem), skopiujmy do folderu webroot – docelowego miejsca dla plików statycznych.
Aby skonfigurować środowisko pracy, należy jeszcze wprowadzić zmiany w dwóch plikach. Na początku settings.py. Tutaj umieścimy podstawowe dane projektu – silnik bazy danych, kod języka czy oznaczenia katalogów:
| DATABASE_ENGINE = 'sqlite3' DATABASE_NAME = 'sklepik.db' TIME_ZONE = 'Europe/Warsaw' LANGUAGE_CODE = 'pl' MEDIA_ROOT = 'webroot' MEDIA_URL = '/files/' MIDDLEWARE_CLASSES = ( ... # Dodaj poniższy wpis wewnątrz... 'django.contrib.flatpages.middleware.FlatpageFallbackMiddleware', ) TEMPLATE_DIRS = ('templates',) INSTALLED_APPS = ( ... # Dodaj poniższy wpis wewnątrz... 'django.contrib.flatpages', 'django.contrib.admin', ) |
| Listing 2 – Kod, który należy uwzględnić w pliku settings.py. |
Polecenia przedstawione na listingu nr 3 należy z kolei umieścić w pliku urls.py:
| from django.conf.urls.defaults import * from django.conf import settings from django.contrib import admin admin.autodiscover() urlpatterns = patterns('', (r'^admin/(.*)', admin.site.root), ) if settings.DEBUG: urlpatterns += patterns('', (r'^files/(?P<path>.*)$', 'django.views.static.serve', {'document_root': settings.MEDIA_ROOT}), ) |
| Listing 3 – Zawartość pliku urls.py. |
W folderze templates/flatpages powinniśmy jeszcze utworzyć plik default.html. Będzie on pełnił funkcję szczegółowego szablonu stron statycznych. W związku z tym wypełnijmy go odpowiednimi znacznikami, przedstawionymi na poniższym listingu:
| {% extends "base.html" %} {% block main_box %} <h2>{{ flatpage.title }}</h2> {{ flatpage.content }} {% endblock %} |
| Listing 4 – Plik default.html |
Przedstawiony szablon rozszerza utworzony wcześniej schemat z pliku base.html, a także informuje system, co powinno znaleźć się w bloku szablonu głównego. Wpisy typu {{ flatpage.title }} powodują oczywiście wstawienie w danym miejscu wartości właściwości title obiektu flatpage.
Teraz powinniśmy jeszcze zadbać o wsparcie bazy danych. Z poziomu powłoki wykonajmy więc w folderze sklepik polecenie python manage.py syncdb, które pozwoli nam utworzyć niezbędne tabele. Gdy system zapyta Would you like to create one now?, wpiszmy yes i odpowiedzmy na dalsze pytania. Dzięki temu, szybko i sprawnie, wygenerowane zostanie konto użytkownika administracyjnego ze wszystkimi uprawnieniami.
Na tym zakończymy konfigurację pierwszej części systemu. Teraz możemy już przystąpić do pierwszego uruchomienia.
Browser: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/530.9 (KHTML, like Gecko) Chrome/2.0.180.0 Safari/530.9
dAREuS
Browser: Opera/9.64 (Windows NT 6.0; U; pl) Presto/2.1.1
Jan Koprowski
Browser: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/530.9 (KHTML, like Gecko) Chrome/2.0.180.0 Safari/530.9
Wy też macie zrobione www w django? (webhosting.pl?)
Browser: Mozilla/5.0 (Windows; U; Windows NT 6.0; pl; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10
dAREuS
Browser: Opera/9.64 (Windows NT 6.0; U; pl) Presto/2.1.1
"W bazie danych Django automatycznie umieści również kolumnę id z kluczem głównym, nie musimy jej więc definiować jawnie."
The Zen of Python: Explicit is better than implicit.
Jan Koprowski
Browser: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/530.9 (KHTML, like Gecko) Chrome/2.0.180.0 Safari/530.9
Browser: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.65 Safari/525.19
Jan Koprowski
Browser: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/530.9 (KHTML, like Gecko) Chrome/2.0.180.0 Safari/530.9
1. nie widziałem jeszcze projektu, który design (i cięcie na HTML) miał robiony po strukturze bazy w przypadku skepu internetowego lub innych podobnych prac zaczynanych od zera;
2. jeśli pierwsze, co zostaje pokazane to aplikacja flatpages i użycie admina, poza konfiguracją to szablon grają pierwsze skrzypce;
3. są projekty, w których na etapie szablonu i konfiguracji znajomość Django może się zakończyć (szczególnie, jeśli stosujesz jakieś aplikację zewnętrzne Django).
Browser: Mozilla/5.0 (X11; U; Linux i686; pl-PL; rv:1.9.0.10) Gecko/2009042523 Ubuntu/9.04 (jaunty) Firefox/3.0.10
Browser: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; pl; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5