Wykład 6: Django - podstawy
Andrzej Krajka
Architektura Django
Porównanie popularnych
frameworków Wynik
http://www.alrond.com/en/2007/jan/25/p erformance-test-of-6-leading-framework s/
CodeIgniter on PHP
Catalyst on Perl
Django on Python
Django on Python with Psyco
RubyOnRails on Ruby
Symfony on PHP
TurboGears on Python (zob. też
http://www.web2py.com/examples/sta tic/web2py_vs_others.pdf
i
http://en.wikipedia.org/wiki/Compariso n_of_web_application_frameworks
)
Nie uwzględniono Pylonsów (Python) i CakePHP.
Django wygrał
Drugie i trzecie miejsce to TurboGears i RoR 1.1.6, - równie szybkie ale różnie zachowują się przy ładowaniu stron
Catalyst. Przykra niespodzianka – oczekiwalibyśmy lepszej pozycji od frameworka PERLa
CodeIgniter. Jak oczekiwaliśmy framework PHP jest wolny ale jest rekomendowany tym którzy pracuja z PHP
Wynik RoR 1.2.1 szokuje – nowsza wersja jest gorsza od starszej!!! Czas response w http_load jest około 2 razy dłuższy niż odpowiedni czas PoP 1.1.6 i więcej zajmuje CPU- przy dużych łańcuchach.
Symfony zajmuje ostatnie miejsce, jest bardzo skomplikowany i wolny, w
porównaniu z Django o 35 (!!!) razy gorszy.
Django jako framework
Framework – aplikacja szkieletowa, która sama w sobie niewiele potrafi, ale za to dostarcza szeregu gotowych narzedzi i wzorców, które umożliwiaja deweloperom skoncentrowanie sie dokładnie na tym, co w danym projekcie jest najważniejsze.
struktura wspomagająca tworzenie, rozwój i testowanie powstającej aplikacji.
➔ Z reguły na framework składają się programy wspomagające, biblioteki kodu źródłowego i inne podobne narzędzia.
Django ma być Pythoniczne
DRY – Do not repeat yourself
Luźne powiązania i elastyczność
Błyskawiczne programowanie
Zestaw podstawowych modułów
◦ Autoryzacja
◦ Dostęp do zasobów
◦ Prezentacja danych
◦ Reakcja na zdarzenia
Django – ograniczenia
Django jest PROSTYM frameworkiem a prosty
framework jest często zbyt prosty, aby mógł znaczaco wpłynąć na wzrost wydajnosci
procesu tworzenia aplikacji, ponieważ:
• wymaga poświęcenia dodatkowego czasu na stworzenie nowych bądź poznanie i integrację gotowych rozwiązań wykonujacych brakujące platformie funkcje,
• nie oferuje wsparcia dla transparentnego
spełnienia zależności miedzykomponentowych.
MVC - MVT (Model-View-Template )
MVC –
struktury danych - MODEL
algorytmy przetwarzania oraz kanały komunikacyjne, które reprezentują określony problem lub dziedzinę rzeczywistości, - WIDOK
komponenty do prezentacji danych oraz obsługę danych wejściowych z klawiatury i myszki, czyli reagowanie na poczynania użytkownika - KONTROLER
Każda z części MVC ma wyłączność na zarządzanie swoją częścią procesu - przykładowo nie może dojść do sytuacji, w której kod odpowiedzialny za wyświetlanie graficznego interfejsu użytkownika znajdzie się w modelu bądź kontrolerze.
Komunikacja między widokiem, a kontrolerem jest łatwa do opisania, ponieważ oba te
komponenty są stworzone do pracy ze sobą, jednak model musi komunikować się z nimi w sposób niejawny.
Model-View-Presenter — zmniejszenie znaczenia widoku na rzecz prezentera, który
posiada pewną wiedzę o GUI oraz o tym, jak mapować poszczególne akcje użytkownika na zmiany modelu oraz zmiany widoku
Pasywny Widok— modyfikacja MVC oraz MVP zakładająca zerwanie powiązania między widokiem, a modelem. Widok nie jest już odpowiedzialny za samodzielną aktualizację — logika jego działania przeniesiona jest do kontrolera. Model View ViewModel
MVVM— modyfikacja wzorca MVC, zawierająca specjalizację modelu prezentacji. Część ViewModel jest tutaj odpowiedzialna za udostępnianie danych z modelu do widoku w
odpowiedni sposób. ViewModel zawiera często większą część logiki związanej z prezentacją danych
Zalety MVC
Zalety:
Separacja danych od sposobu ich reprezentacji;
poszczególnymi komponentami mogą zajmować się niezależni programiści;
łatwo utrzymywać i modernizować kod dużych aplikacji;
Możliwość wymiany np. silnika bazy danych, systemu szablonów, programisty etc.
MVC w Django:
Podstawowe elementy
Model
Template
View
Gdzie kontroler?
Kontroler jako taki nie jest obecny, można przyjąć że jest nim urls.py
ORM – Mapowanie obiektowo-relacyjne
■ Odzielenie niskopoziomowych operacji na zbiorze danych od ich reprezentacji w
aplikacji
■ Wymiana silnika bazy danych bez zmiany kodu aplikacji
■ Jednolita reprezentacja
Architektura
urls.py
models.py
views.py
settings.py
class Person(models.Model):
imie = models.CharField(max_length=30) nazwisko = models.CharField(max_length=30) dataur=models.DateField()
foto=models.ImageField(upload_to="media") wzrost=models.DecimalField(max_digits=5, decimal_places=2)
admail=models.EmailField() odsyl=models.SlugField() def __unicode__(self):
return self.nazwisko urlpatterns = patterns('',
url(r'^person$', 'osoba.prg1.views.strona1'), (r'^(?P<slug>[\w\-_]+)/pdf/$','prg1.views.shpdf'),
url(r^hello$, ‘osoba.prg2’, {“os”= 4}, “name”=apl)
url(r'^admin/doc/',
include('django.contrib.admindocs.urls')),
def strona1(request):
…
return render_to_response ("strona1.html", dict1) def strona2(request):
…
return
HttpResponse(u"Witam PYTHONa!") DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3', 'NAME': 'person', }
}
INSTALLED_APPS = ( ‘my.app’,
'django.contrib.auth',
Ustawienia – settings.py
DATABASE_ENGINE = sqlite3’ # ’postgresql_psycopg2’,’postgresql’,’mysql’, # ’sqlite3 ’, ’oracle’.
DATABASE_NAME = 'baza' # Nazwa bazy danych lub ścieżka do bazy # sqlite3
DATABASE_USER = '' # Uzytkownik bazy: nie stosuj do sqlite3.
DATABASE_PASSWORD = '' # Hasło użytkownika: nie stosuj do sqlite3.
DATABASE_HOST = '' # host do bazy danych, podaj puste dla # lokalhosta.
DATABASE_PORT = '' # Podaj port jesli niestandartowy: nie stosuj #do sqlite3
TIME_ZONE = ’Europe/Warsaw’
LANGUAGE_CODE = ’pl’
Ustawienia – baza danych
Ustawienia – konsola
python django-admin.py startproject my1
(C:\Python27\python C:\Python27\Lib\site-
packages\django\bin\django-admin.py startproject my1)
python manage.py runserver
python manage.py startapp
myapp
Django – budowa aplikacji
Powtórne użycie aplikacji
python manage.py startapp Aplikacja1
Projekt
Aplikacja 1
Model
View
URL
Aplikacja 2
Model
View
Url
Aplikacja 3
Model
View
Url
Django - model
Definiuje się pythonowe klasy dziedziczące po models.Model
# -*- coding: utf-8 -*-
from django.db import models
from django.contrib.auth.models import User
# Create your models here.
class Message(models.Model):
author = models.ForeignKey(User,related_name="author") title = models.CharField(maxlength=50)
pub_date = models.DateTimeField(auto_now=True) body_text = models.CharField(maxlength=200)
def __unicode__(self):
return self.author + self.title class Meta:
ordering = ('-pub_date',)
Django – model; Tworzenie i synchronizacja tabel
■ Następie tworzymy kod SQL (i tworzymy tabele)
[jas@misia twitter]$ python manage.py sql messageBoard
BEGIN;
CREATE TABLE "messageBoard_message" (
"id" serial NOT NULL PRIMARY KEY,
"author_id" integer NOT NULL REFERENCES "auth_user" ("id") DEFERRABLE INITIALLY DEFERRED,
"title" varchar(50) NOT NULL,
"pub_date" timestamp with time zone NOT NULL,
"body_text" varchar(200) NOT NULL );
COMMIT;
■ Synchronizacja tabel:
[jas@misia twitter]$ python manage.py syncdb
Django – model; Dostosowanie
■ W klasie definiującej dany model możemy umieszczać własne metody, które mają dostęp do atrybutów danej klasy
class Message(models.Model):
author = models.ForeignKey(User,related_name="author") title = models.CharField(maxlength=50)
pub_date = models.DateTimeField(auto_now=True) body_text = models.CharField(maxlength=200) def get_title(self):
return "%s" %(self.title) class Admin:
pass
Własna metoda
Django – URLconf – zawiadowca stacji
Projekt
URLconf Aplikacja
URLconf
Wzorzec URL Metoda VIEW
Django - URLconf
Zapytanie od użytkownika
Import ROOT_URLCONF
Przeszukanie urlpatterns
W przypadku odnalezienia, wywołanie odpowiedniej
funkcji z przekazanymi parametrami
Django - URLconf
from django.conf.urls.defaults import * urlpatterns = patterns('',
(r'^articles/2009/$', ‘blog.views.special_case_2003'), (r'^articles/(\d{4})/$', ‘blog.views.year_archive'),
(r'^articles/(\d{4})/(\d{2})/$', ‘blog.views.month_archive'), (r'^articles/(\d{4})/(\d{2})/(\d+)/$', ‘blog.views.article_detail'),
Zapytanie:
/ articles/2008/05 /
Wywołana funkcja:
blog.views.month_archive(request, '2008', ‘05')
Django - views
■ Odpowiada za prezentacje danych
■ Definiowany w pliku view.py w ramach aplikacji
■ Każda metoda (funkcja) wywoływana przez URLConf musi
zwracać obiekt klasy HttpResponse a jej parametrm (być może nie jedynym) musi być request.
from django.http import HttpResponse def index(request):
return HttpResponse("Hello, world") HttpResponseForbidden
HttpResponseServerError
HttpResponeRedirect(‘/login/’)
render_to_response(‘base.html’, {‘osoba’:persona, ‘dana’:dana},
context_instance=requestContext(request))
Django - Widoki generyczne
■ Zdefiniowane widoki do najpopularniejszych czynności
django.views.generic.simple.direct_to_template
➔ Parsuje podany w parametrze szablon
django.views.generic.list_detail.object_list
➔ Listuje wpisy z danego modelu
django.views.generic.list_detail.object_detail
➔ Pokazuje szczegóły wskazanego wpisu z modelu
CRUD (Create/update/delete)
➔ Zestaw widoków umożliwiających łatwe
tworzenie/edycje/usuwanie wpisów z modelu
Django - Szablony
■ Natywny system szablonów podobny do Smarty
■ Możliwość użycia innych systemów szablonów
■ Szablony obsługują dziedziczenie
■ Dostępne elementy
Zmienne przekazywane z view'era {{ zmienna }}, {{ zmienna.atrybut }}
Filtry np. {{ zmienna|upper }}
Tagi m.in.
➔ block {% block content %} {% endblock %}
➔ for {% for item in item_list %} {% endfor %}
➔ If {% if sth %} {% endif %}
Django - szablon
Base.html
<html>
<style type="text/css">
body { color: #efd; background: #453; padding: 0 5em; margin:
0 }
h1 { padding: 2em 1em; background: #675 }
h2 { color: #bf8; border-top: 1px dotted #fff; margin-top: 2em } p { margin: 1em 0 }
</style>
<body>
<h1>Moj blog</h1>
{% block content %}
{% endblock %}
</body>
</html>
Django – plik dziedziczący z szablonu
Archive.html
{% extends "base.html" %}
{% block content %}
<h2>Dodaj nową wiadomość</h2>
<div style="font-size: 70%;">
<form action="" method="post">
<table>
{{ form }}
</table>
<input type="submit" value="Wyślij" />
</form>
</div>
{% endblock %}
Django – panel Admina
urls.py
from django.conf.urls.defaults import from django.contrib import admin admin.autodiscover()
urlpatterns = patterns{ " .
url(r '^admin/doc/’, include(‘django.contrib.admindocs.urls’)) , url(r '^admin/’, include(admin.site.urls)) ,
} settings.py
INSTALLED_APPS = (
# Uncomment the next line to enable the admin : ' django.contrib.admin' ,
# Uncomment the next line to enable admin documentation : ' django.contrib.admindocs ' ,
models.py
from django.db import models from django.contrib import admin class BlogPost (models .Model ) :
…
admin.site.register(BlogPost) [admin.site.register( BlogPost , BlogPostAdmin)])
