Django jak i wiele innych frameworków stosuje wzorzec MVC, ale z małą różnicą. W Django nie mamy Model-View-Controler lecz Model-Template-View - MTV.
Model opisuje strukturę tabel w bazie danych,
Template czyli zwykły szablon opisuje wygląd, a
View czyli widok pełni rolę kontrolera - opisuje działanie aplikacji. Różnica MVC - MTV polega na innym nazwaniu komponentów. Teraz zajmiemy się poznaniem
widoków.
We
wprowadzeniu do django stworzyliśmy prostą aplikację, w której wykorzystaliśmy widok generyczny, jednak nie zawsze będziemy mogli skorzystać z takiego predefiniowanego widoku. Do definiowania własnych widoków służy plik:
NAZWA_APLIKACJI/views.py
W przypadku projektu z wprowadzenia:
news/views.py
Plik ten jest pusty i możemy umieszczać w nim wszystkie nasze widoki. Każdy widok to funkcja przyjmująca jeden obowiązkowy parametr
request i zwracająca obiekt
HttpRequest. Brzmi strasznie ale w rzeczywistości jest to bardzo proste. Każdy widok musimy przypisać do konkretnego URLa poprzez regułę w
urls.py (o regułach w kolejnym artykule)... Dobra koniec, czas na przykład. Do
news/views.py dodaj kod:
from django.http import HttpResponse
def test(request):
return HttpResponse('To jest <b>tekst</b>')
Do
urls.py dodaj regułę:
(r'^test/$', 'news.views.test'),
Teraz uruchom serwer deweloperski i otwórz w przeglądarce
http://localhost:8080/test/:
python manage.py runserver 8080
W przeglądarce zobaczysz tekst z widoku. Właśnie stworzyliśmy prosty widok oraz przypisaliśmy go do URLa /test/ za pomocą prostej reguły. Zwracamy
HttpResponse i wszystko działa, lecz dla 99% przypadków skorzystamy z
render_to_response - nakładki na HttpResponse stosującej szablony oraz
HttpResponseRedirect - przekierowania na inny adres URL aplikacji.
Oto najprostsze zastosowanie render_to_response, zastąp kod
news/views.py:
from django.shortcuts import render_to_response
def test(request):
return render_to_response('test.html')
Oraz stwórz szablon:
templates/test.html o kodzie:
I gotowe. Odśwież stronę - efekt powinien być ten sam. Teraz zajmiemy się się dodatkowymi możliwościami. By
przekazać do szablonu dane należy podać je jako drugi parametr render_to_response w postaci słownika:
from django.shortcuts import render_to_response
def test(request):
return render_to_response('test.html', {'imie': 'Piotr', 'framework': 'django'})
A w szablonie wystarczy wpisać:
{{ imie }} - {{ framework }}
W szablonie poszczególne zmienne dostępne są poprzez klucze słownika.
render_to_response stosujemy w każdym normalnym widoku, gdy chcemy wyświetlić daną stronę na bazie szablonu. Należy pamiętać, że niektóre czynności można zrealizować przez generyczne widoki.
Przekierowanie jest bardzo proste:
from django.http import HttpResponseRedirect
def test(request):
return HttpResponseRedirect("/")
Jako parametr podajemy adres URL. Przekierowania stosujemy np. do przekierowania użytkownika, który wysłał formularz (po logowaniu - na jego profil, po dodaniu newsu - na stronę newsa itp.)
Parametr
request przekazywany do każdego widoku zawiera wiele przydanych danych, przedstawionych poniżej. Wszystkie atrybuty poza
session powinny być używane "tylko do odczytu".
- path: łańcuch reprezentujący ścieżkę do żądanej strony bez domeny.
- method: łańcuch określający metodę żądania strony (GET albo POST)
- GET: słownikopodobny obiekt zawierający wszystkie parametry żądań GET. Patrz "Obiekty QueryDict"
- POST: to samo dla żądań POST
- REQUEST: słownikopodobny obiekt załączający dane z POST (najpierw) oraz z GET
- COOKIES: słownik zawierający dane ciasteczek (klucze i wartości to łańcuchy)
- FILES: słownikopodobny obiekt zawierający dane o wysłanych plikach (przez formularz). Kluczem jest nazwa pola formularza a wartością słownik zawierający trzy klucze:
filename -- Nazwa pliku, łańcuch
content-type -- Typ mime pliku
content -- zawartość pliku
- META: słownik zawierający nagłówki HTTP, przykładowe to:
CONTENT_LENGTH
CONTENT_TYPE
HTTP_ACCEPT_ENCODING
HTTP_ACCEPT_LANGUAGE
HTTP_REFERER
HTTP_USER_AGENT
QUERY_STRING
REMOTE_ADDR
REMOTE_HOST
REQUEST_METHOD
SERVER_NAME
SERVER_PORT
- user: obiekt django.contrib.auth.models.User (jeżeli używane AuthenticationMiddleware) w przypadku zalogowanego użytkownika lub django.contrib.auth.models.AnonymousUser w przypadku nie zalogowanego.
- session: dane sesji.
- has_key(): zwróci Prawda/Fałsz jeżeli request.GET lub request.POST mają podany klucz.
- get_full_path(): zwróci ścieżkę z żądania wraz z "query string" jeżeli istnieje.
- is_secure(): zwróci True jeżeli stosujemy połączenie HTTPS.
Obiekt QueryDict jest nieco zmodyfikowanym słownikiem zdolnym przechowywać wiele wartości dla jednego klucza. Dodatkowe metody (szczegóły w dokumentacji django):
- getlist(key): zwróci listę z wartościami przypisanymi dla danego klucza
- list(): zwraca w listach wszystkie wartości z żądania:
>>> q = QueryDict('a=1&a=2&a=3')
>>> q.lists()
[('a', ['1', '2', '3'])]
Najprostsze zobrazowanie zawartości request będzie jej wyświetlenie.
print wyświetli zawartość request do okna terminala z działającym serwerem deweloperskim:
def test(request):
print request
return render_to_response('test.html')
- Dodane: 14.07.2008 przez riklaunim