RkBlog

Hardware, programming and astronomy tutorials and reviews.

Widoki Django, obiekty Request i Response

  1. RkBlog
  2. PL
  3. Programowanie
  4. Python
  5. Django
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.

Budowa 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.

render_to_response

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: 
To jes <b>tekst</b>
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.

HttpResponseRedirect

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.)

Obiekt HttpRequest

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.

METODY

  • 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.

Obiekty QueryDict

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'])]

Przykład

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')
RkBlog

Django, 14 July 2008, Piotr Maliński

Comment article