Wykład 6: Django

(1)

Wykład 6: Django - podstawy

Andrzej Krajka

(2)

Architektura Django

Porównanie popularnych

frameworków Wynik

http://www.alrond.com/en/2007/jan/25/pe rformance-test-of-6-leading-

frameworks/

 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/stati c/web2py_vs_others.pdf

i

http://en.wikipedia.org/wiki/Comparison_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.

(3)

Warstwa pośrednicząca

żądania

Plik URLconf urls.py

Warstwa pośrednicząca

widoku

Widoki generyczne, półgeneryczne i własne views.py

Zbiór

modeli ORM

Zbiór szablonów Odpowiedż

Warstwa posrednicząca

odpowiedzi INTERNET

HTTPD/Serwer sieciowy

Odpowiedź HTTP Żądanie http POST/GET

Python DB-API Adapter bazodanowy

Baza danych SZBD

(4)

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

(5)

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.

(6)

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

(7)

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

(8)

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

(9)

Architektura

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',

(10)

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’

(11)

Ustawienia – baza danych

(12)

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

(13)

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

(14)

Django - 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',)

(15)

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

(16)

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

(17)

Django – URLconf – zawiadowca stacji

Projekt

URLconf Aplikacja

URLconf

Wzorzec URL Metoda VIEW

(18)

Django - URLconf

Zapytanie od użytkownika

Import ROOT_URLCONF

Przeszukanie urlpatterns

W przypadku odnalezienia, wywołanie odpowiedniej funkcji z przekazanymi parametrami

(19)

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

(20)

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

(21)

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

(22)

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 %}

(23)

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>

(24)

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 %}

(25)

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

(26)

Django – panel Admina

(27)

Django – panel Admina –

dostęp do tabel

(28)

Django – Dostep do tabel z

Firefoxa

(29)