Szkielety tworzenia aplikacji

Transkrypt

1 Szkielety tworzenia aplikacji dr inż. Andrzej Grosser Instytut Informatyki Teoretycznej i Stosowanej Politechnika Częstochowska 2017/2018

2 Kwestie organizacyjne Kontakt: mail: strona: konsultacje: pokój 204 ul. Dąbrowskiego 73, po wcześniejszym umówieniu drogą mailową Szkielety tworzenia aplikacji 2

3 Plan przedmiotu Wprowadzenie do technologii szkieletowych. Django instalacja i konfiguracja założenia projektowe model - ORM podstawy tworzenia stron - widok kontroler dopracowywanie modelu testy administrator, użytkownik - wprowadzenie ról web services Qt Szkielety tworzenia aplikacji 3

4 Budowanie aplikacji Szkielety tworzenia aplikacji 4

5 MVC Model-View-Controller wzorzec projektowy wykorzystywany w inżynierii oprogramowania, izolujący logikę biznesową od warstwy prezentacji danych, wspierajacy niezależne projektowanie, realizację i testowanie poszczególnych elementów aplikacji. Szkielety tworzenia aplikacji 5

6 Klocki górą logika aplikacji Szkielety tworzenia aplikacji 6

7 Klocki górą logika aplikacji interfejs użytkownika Szkielety tworzenia aplikacji 7

8 Klocki górą logika interfejs zarządzanie, aplikacji użytkownika komunikacja Szkielety tworzenia aplikacji 8

9 Model logika biznesowa - model składowania danych warstwa samodzielna zmiany w strukturze danych nie wpływają na pozostałe części aplikacji przenośny typy: aktywny i pasywny Szkielety tworzenia aplikacji 9

10 Widok logika prezentacji - interfejs użytkownika referencje do danych różnorodność technologii (XHTML, PHP, XML, PDF, FLASH, RSS, SOAP itd) pobiera, pokazuje, ale nie modyfikuje danych łatwa rozbudowa Szkielety tworzenia aplikacji 10

11 Kontroler komunikacja może zmieniać stan modelu odświeża widok przełącza sterowanie Szkielety tworzenia aplikacji 11

12 Zastosowanie duże projekty przewidziana ciągła ewolucja aplikacji i stosowanych w niej technologii duży zespół realizujący aplikację możliwość wykorzystania części projektu w innych realizacjach Oracle ADF, Java Swing, Spring Framework, Ruby on Rails, Django, Symfony i wiele innych Szkielety tworzenia aplikacji 12

13 Odmiany Model-View-Presenter Presentation-Abstraction-Control Hierarchical Model-View-Controller Pasywny widok Szkielety tworzenia aplikacji 13

14 Szkielety aplikacji Szkielety tworzenia aplikacji 14

15 Szkielety aplikacji Framework - szkielet budowy aplikacji. Definiuje strukturę aplikacji oraz ogólny mechanizm jej działania, dostarcza zestaw komponentów i bibliotek ogólnego przeznaczenia do wykonywania określonych zadań. Szkielety tworzenia aplikacji 15

16 Cechy gotowy szkielet narzucony przepływ sterowania domyślna konfiguracja komponenty do rozbudowy zdefiniowana i zamknięta struktura wewnętrzna Szkielety tworzenia aplikacji 16

17 Zalety i wady szybka realizacja projektu poprawa jakości kodu większa niezawodność wsparcie twórców frameworku Szkielety tworzenia aplikacji 17

18 Zalety i wady szybka realizacja projektu poprawa jakości kodu większa niezawodność wsparcie twórców frameworku złożoność niższa wydajność koszt szkoleń Szkielety tworzenia aplikacji 18

19 Django Django - wysokopoziomowy, framework przeznaczony do tworzenia aplikacji internetowych, napisany w Pythonie. nazwę wymawiamy dżango nazwa pochodzi od imienia gitarzysty Django Reinhardta Powstał pod koniec 2003 roku jako ewolucyjne rozwinięcie aplikacji internetowych, tworzonych przez grupę programistów związanych z Lawrence Journal-World W 2005 roku kod Django został wydany na licencji BSD Django opiera się na wzorcu projektowym Model-View-Template Szkielety tworzenia aplikacji 19

20 Cechy Django I Automatycznie generowany i kompletny panel administracyjny, z możliwością dalszego dostosowywania Przyjazne adresy dokumentów z możliwością dowolnego ich kształtowania Prosty lecz funkcjonalny system szablonów czytelny zarówno dla grafików jak i dla programistów Oddzielenie logiki aplikacji (widok) logiki biznesowej (model) wyglądu (szablony) oraz baz danych Wsparcie dla wielojęzycznych aplikacji Bardzo duża skalowalność i wydajność pod obciążeniem Wydajne systemy cache owania, obsługa Memcached Własny, prosty serwer do testowania aplikacji Szkielety tworzenia aplikacji 20

21 Cechy Django II Współpracuje z Apache poprzez WSGI (domyślnie) i mod python oraz z innymi serwerami poprzez protokoły FastCGI i SCGI DRY czyli zasada nie powtarzaj się w odniesieniu do tworzenia aplikacji, (np. strukturę bazy danych Django generuje ze zwykłych klas Pythona) Posiada ORM wysokiego poziomu pozwalający na łatwe i bezpieczne operowania na bazach danych bez użycia SQL Obsługuje następujące bazy danych: PostgreSQL, MySQL, SQLite oraz Oracle Rozpowszechniany jest na licencji BSD Szkielety tworzenia aplikacji 21

22 Architektura MVT Model - opisuje strukturę danych, dotyczy schematu bazy danych View - kontroluje jakie dane mają dotrzeć do użytkownika Template - opisuje jak dane będą prezentowane Controler - dla Django nadzoruje parsowaniem url Szkielety tworzenia aplikacji 22

23 Architektura Django Szkielety tworzenia aplikacji 23

24 Moduły Django Interface administracyjny (CRUD interface) System uwierzytelniania System komentarzy Moduł wsparcia formularzy Obsługa sesji Obsługa cache owania Moduł internacjonalizacji Moduł lokalizacji itd... Szkielety tworzenia aplikacji 24

25 Kroki tworzenia aplikacji zaprojektuj aplikację, zainstaluj niezbędne składniki, zdefiniuj ustawienia bazy Settings.py, zdefiniuj model, dodaj niezbędne moduły, napisz szablony, zdefiniuj warstwę widoku, zdefiniuj mapowanie url, testuj aplikację, wdróż ją. Szkielety tworzenia aplikacji 25

26 Instalacja I Instalacja Pythona - Instalacja Apache i mod_pythona Instalacja SZBD: PostgreSQL, MySQL, Oracle lub SQLite Instalacja sterowników bazy danych PostgreSQL - pakiet psycopg MySQL - MySQLdb SQLite - pysqlite Oracle - cx_oracle Zapewnienie uprawnień do tworzenia i modyfikowania tabel w bazie danych Usunięcie starych wersji Django Instalacja kodu Django Instalacja z paczek dla określonych dystrybucji Instalacja oficjalnego wydania Szkielety tworzenia aplikacji 26

27 Instalacja II Instalacja wersji rozwojowej git clone Test poprawności instalacji (np.: import modułu django): >>> import django >>> django.version (1, 7, 0, final, 0) >>> django.get_version() 1.7 Szkielety tworzenia aplikacji 27

28 Tworzenie projektu Projekt to zestaw ustawień dla instancji Django zawierający konfigurację bazy danych, opcje specyficzne dla Django oraz ustawienia specyficzne dla aplikacji. Tworzenie katalogu projektu (nie jest zalecane tworzenie go w /var/www), Przejście do katalogu projektu Wygenerowanie projektu django-admin.py startproject pracuj Szkielety tworzenia aplikacji 28

29 Tworzenie projektu I Katalog pracuj zawiera cztery pliki: manage.py pracuj/ init.py settings.py urls.py wsgi.py init.py - plik wymagany przez Pythona, manage.py - narzędzie wiersza poleceń, które umożliwia interakcję z projektem Django na wiele sposób (python manage.py help), settings.py - ustawienia i konfiguracja dla projektu Django, urls.py - główny plik odwzorowania adresów URL dla projektu, wsgi.py - plik konfiguracyjny dla WSGI Szkielety tworzenia aplikacji 29

30 Tworzenie aplikacji I Aplikacja jest tworzona poleceniem: python manage.py startapp aplikacja Po utworzeniu w katalogu nadrzędnym projektu pojawi się katalog aplikacji zawierający cztery pliki: init.py - katalog ma być traktowany jako pakiet, admin.py - dostosowanie interfejsu administratora, apps.py - zawiera metadane dla aplikacji, models.py - modele, tests.py - testy, views.py - widoki. Szkielety tworzenia aplikacji 30

31 Tworzenie projektu I Uruchomienie serwera deweloperskiego python manage.py runserver Pod adresem strona powitalna projektu Szkielety tworzenia aplikacji 31

32 Pierwsza strona w Django I Realizacja widoku: tworzenie pliku o nazwie views.py o zawartości: from django.http import HttpResponse def hello(request): return HttpResponse("Witaj, świecie!") Widok jest zwykłą funkcją Pythona, która jako pierwszy parametr przyjmuje obiekt HttpRequest, a jako odpowiedź zwraca obiekt HttpResponse. Szkielety tworzenia aplikacji 32

33 Pierwsza strona w Django II edycja pliku urls.py, który domyslnie zawiera: from django.conf.urls.defaults import * # Uncomment the next two lines to enable the admin: # from django.contrib import admin # admin.autodiscover() urlpatterns = patterns(, # Example: # (r ^mysite/, include( mysite.foo.urls )), # Uncomment the admin/doc line below and add django.contrib.admindocs # to INSTALLED_APPS to enable admin documentation: # (r ^admin/doc/, include( django.contrib.admindocs.urls )), ) # Uncomment the next line to enable the admin: # (r ^admin/(.*), admin.site.root), Szkielety tworzenia aplikacji 33

34 Pierwsza strona w Django III from django.conf.urls.defaults import * from pracuj.views import hello urlpatterns = patterns(, #... ( ^hello/$, hello), ) adres Szkielety tworzenia aplikacji 34

35 Schemat działania I Przychodzi żądanie dotyczące /hello/. Django określa główny plik URLconf, analizując zawartość zmiennej ROOT_URLCONF. Django przegląda wszystkie wzorce URL z pliku URLconf w poszukiwaniu pierwszego pasującego do /hello/. Jeśli znajdzie dopasowanie, wywołuje powiązaną z nim funkcję widoku. Funkcja widoku zwraca HttpResponse. Django konwertuje HttpResponse na odpowiednią odpowiedź HTTP zawierająca stronę WWW. Szkielety tworzenia aplikacji 35

36 HTML HTML - Hyper Text Markup Language język opisu struktury strony, a nie jej wyglądu język znaczników, a nie język programowania zawiera bogaty zbiór znaczników opisujących elementy strony: nagłówki, akapity, listy i tabele. przeglądarka poprawnie interpretuje narzucony styl elementu, dzięki znacznikom w jakich został on osadzony Szkielety tworzenia aplikacji 36

37 Historia HTML 1980: fizyk Tim Berners-Lee (CERN) zaproponował ENQUIRE, do roku 1990 opracował HTML 1993: draft opublikowany przez IETF (Internet Engineering Task Force) 1995: HTML 2.0 Styczeń 1997: HTML 3.2 (rekomendacja W3C (World Wide Web Consortium)) Grudzień 1997: HTML 4.0 (rekomendacja W3C) (Strict, Transitional, Frameset) 1999: HTML 4.01 (rekomendacja W3C) zawieszenie HTML, prace nad XHTML 2008: working draft HTML5 (prace miały potrwać do 2022) Październik 2014: HTML 5.0 Szkielety tworzenia aplikacji 37

38 HTML/XHTML - zasady znaczniki - słowa kluczowe zawarte w nawiasach kątowych np.: <table> znaczniki mogą posiadać atrybuty, których wartości zawarte są w apostrofach lub w cudzysłowie np: src="przyk.gif" większość znaczników wymaga zamknięcia, np.: <h5>tekst</h5> znaczniki niepuste zawsze mają znacznik końcowy, np.: <p>dowolny tekst</p> znaczniki puste (logiczne) muszą być zakończone znakiem />, np.: <br /> wszystkie słowa kluczowe: nazwy znaczników i atrybutów, powinny być pisane małymi literami, np.: <img src="przyk.gif" /> pliki mogą nosić rozszerzenie.html lub.htm Szkielety tworzenia aplikacji 38

39 Struktura pliku <html> <!-- otwarcie strony--> <head> <!-- nagłówek strony--> <title>tytuł strony</title> <meta charset=utf-8" /> </head> <body> <!-- ciało strony--> <p>właściwa zawartość...</p> </body> </html> <!-- zamknięcie strony--> Szkielety tworzenia aplikacji 39

40 Nowe znaczniki HTML5 Najważniejsze nowe znaczniki: header - nagłówek footer - stopka nav - pasek nawigacyjny aside - pasek boczny section - grupowanie powiązanych ze sobą treści article - samodzielna treść figure - pozwala powiązać element z podpisem Szkielety tworzenia aplikacji 40

41 Struktura pliku HTML5 I <!DOCTYPE html> <html> <head> <title>tytuł</title> <meta charset="utf-8"/> </head> <body> <header> <h1>nagłówek</h1> </header> Szkielety tworzenia aplikacji 41

42 Struktura pliku HTML5 II <nav> <ul> <li><a href="#">odnośnik1</a></li> <li><a href="#">odnośnik2</a></li> </ul> </nav> <section> <article> <header> <h1><a href="#">tytuł 1</a></h1> </header> <section> <p>przykładowy wpis</p> </section> </article> </section> Szkielety tworzenia aplikacji 42

43 Struktura pliku HTML5 III <aside> <h2>odnośniki:</h2> <ul> <li><a href="#">odnośnik1</a></li> </ul> </aside> <footer> <p>struktura HTML5</p> </footer> </body> </html> Szkielety tworzenia aplikacji 43

44 Podstawowe znaczniki I nagłówki <h1>nagłówek 1</h1>, <h2>nagłówek 2</h2>, <h3>nagłówek 3</h3>, <h4>nagłówek 4</h4>, <h5>nagłówek 5</h5>, <h6>nagłówek 6</h6> paragrafy <p>pierwszy paragraf.</p> <p>drugi paragraf<br /> ze złamaniem linii.</p> obrazy <img src="w3schools.jpg" width="104" height="142" /> <!-- Komentarz --> Szkielety tworzenia aplikacji 44

45 Podstawowe znaczniki II listy numerowane - oznaczane liczbami <ol> <li>pierwszy element listy</li> <li>drugi element listy</li> </ol> wypunktowane - oznaczone kropkami lub symbolami <ul> <li>pierwszy element listy</li> <li>drugi element listy</li> </ul> definicji <dl> <dt>pojęcie</dt><dd>definicja</dd> </dl> Szkielety tworzenia aplikacji 45

46 Odnośniki I <a href="./plik.html" target="_blank">odniesienie</a> Rodzaje ścieżek do pliku: względna - określa położenie pliku z punktu widzenia bieżącej pozycji w drzewie katalogów: <a href="./plik.html">odniesienie</a> bezwzględna - całkowita ścieżka dostępu do pliku. <a href="/home/user/plik.html">odniesienie</a> adres URL - całkowita ścieżka dostępu do pliku znajdującego się na innym serwerze. <a href=" Odniesienie </a> Szkielety tworzenia aplikacji 46

47 Odnośniki II Połączenia do określonych miejsc na stronie: <a href="./plik.html#nazwa">odniesienie</a> <!-- W HTML --> <a name="nazwa">miejsce odniesienia</a> <!-- W XHTML --> <a id="nazwa">miejsce odniesienia</a> Szkielety tworzenia aplikacji 47

48 Style semantyczne Style semantyczne - określają rolę tekstu w dokumencie: <em></em> - tekst wyróżniony <strong></strong> - tekst podwójnie wyróżniony <code></code> - fragment kodu <samp></samp> - tekst przykładowy <var></var> - do nazw zmiennych <dfn></dfn> - definicja <cite></cite> - krótki cytat <address></address> - adresy <blockquote></blockquote> - blok długiego cytatu Szkielety tworzenia aplikacji 48

49 Style prezentacyjne Style prezentacyjne - określają sposób w jaki tekst powinien zostać sformatowany: <b></b> - pogrubienie <i></i> - kursywa <tt></tt> - czcionka maszynowa  - indeks dolny  - indeks górny <big></big> - czcionka powiększona <small></small> - czcionka pomniejszona Szkielety tworzenia aplikacji 49

50 Tabele Tabele ograniczone znacznikiem <table></table>, zawierają: <thead></thead> - część nagłówkową <tfoot></tfoot> - stopkę <tbody></tbody> - "ciało" tabeli <tr></tr> - wiersze <th></th> - komórki nagłówka <td></td> - zwykłe komórki <colgroup></colgroup> - grupa kolumn <col /> - atrybuty jednej kolumny Szkielety tworzenia aplikacji 50

51 Przykład tabeli <table border="1"> <thead> <tr> <th>nagłówek1</th> <th>nagłówek2</th> </tr> </thead> <tbody> <tr> <td>dane1</td> <td>dane2</td> </tr> </tbody> </table> nagłówek1 dane1 nagłówek2 dane2 Szkielety tworzenia aplikacji 51

52 Formularze Formularze używane do przesyłu informacji od użytkownika do serwera otoczone znacznikiem <form></form> - wewnątrz poszczególne elementy formularza i kod HTML tworzący cały układ (akapity, nagłówki, tabele) na jednej stronie można umieścić dowolną liczbę formularzy, ale nie wolno ich zagnieżdżać Szkielety tworzenia aplikacji 52

53 Formularze cd <form> zawiera dwa podstawowe atrybuty: action - względny lub pełny adres URL, pod który należy przesłać zawartość pól formularza, by otrzymać odpowiedź. method - metoda przesyłania danych od klienta do serwera: get - dane formularza są spakowane i dołączone do URL a, który został wskazany jako wartość action. post - dane przesyłane są niezależnie od odwołania do skryptu. Skrypt otrzymuje je na standardowym wejściu. Szkielety tworzenia aplikacji 53

54 Metody get i post Metoda get Metoda post POST /something HTTP/1.1 Host: server Content-Length: 21 Content-Type: application/x-www-form-urlencoded value1=foo&value2=bar Szkielety tworzenia aplikacji 54

55 Formularze - składowe Znacznik <input /> definiuje prosty element formularza, który posiada dwa atrybuty: type i name. Atrybut type definiuje rodzaj elementu formularza : "text", "radio", "checkbox", "password", "submit", "reset", "button", "file", "hidden". Atrybut name wskazuje nazwę elementu, która jest niezbędna dla skryptu do odróżnienia poszczególnych pól od siebie. Skrypt pobiera dane z formularza w postaci: nazwa-wartość. Jako wartość przyjmowane są rzeczywiste dane wprowadzane przez użytkownika, natomiast nazwą jest wartość atrybutu name. Szkielety tworzenia aplikacji 55

56 Przykład formularza <form name="input" action="html_form_action.asp" method="get"> <p>czym najczęściej dojeżdżasz do pracy?<br /> <input type="checkbox" name="srodek_kom" value="rower" /> Rowerem<br /> <input type="checkbox" name="srodek_kom" value="auto" /> Samochodem<br /> <input type="checkbox" name="srodek_kom" value="zbuta" /> Na piechotę<br /><br /> <input type="submit" value="zatwierdź" /> </p> </form> Szkielety tworzenia aplikacji 56

57 Przykład formularza cd Szkielety tworzenia aplikacji 57

58 Listy wyboru Opcje wyboru umożliwiają użytkownikowi wybranie z listy przewijanej jednej lub wielu pozycji. Opcje wyboru są wprowadzane za pomocą znacznika <select>: <p>wybierz wykształcenie <select name="wyksztalcenie"> <option>podstawowe</option> <option>średnie</option> <option>wyższe</option> </select> </p> Szkielety tworzenia aplikacji 58

59 Obszary tekstowe Obszary tekstowe są polami wprowadzania danych, w które użytkownik może wprowadzać wiele linii tekstu. Do wprowadzania tekstu służy znacznik <textarea>: <p>wpisz komentarz:<br /> <textarea name="komentarz" rows="10" cols="50"> </textarea> </p> Szkielety tworzenia aplikacji 59

60 Elementy ukryte Atrybut type znacznika <input /> może przyjąć wartość "hidden". W takim wypadku element formularza nie będzie wyświetlany. <input type="hidden" name="dane_osobowe" value="on"> Mogą być przesyłane w ten sposób dodatkowe dane: numery ankiety, opis formularza itp. Szkielety tworzenia aplikacji 60

61 Przesyłanie plików <form enctype="multipart/form-data" method="post" action=" <p>wyślij plik: <input type="file" name="userfile" /> <input type="submit" value="prześlij" /> </p> </form> Szkielety tworzenia aplikacji 61

62 Zanik struktury HTML Skutki zaniku struktury w stronach HTML: utrudnione indeksowanie stron, a co za tym idzie ograniczanie możliwości narzędzi wyszukujących obniżenie dostępności strony (np. dla niewidomych) trudności w zarządzaniu i "konserwacji" Szkielety tworzenia aplikacji 62

63 Powstanie CSS W3C zauważa problem zanikania struktur HTML i zaśmiecania kodu znacznikami definiującymi wygląd strony. W roku 1995 rozpoczyna budowanie CSS W 1996 zalecano stosowanie CSS w takim samym stopniu jak HTML (CSS1 - Cascading Style Sheeets Level 1) CSS2 - powstał w 1998 roku poszerzając funkcjonalności CSS1 CSS3 - w fazie rozwoju Szkielety tworzenia aplikacji 63

64 Podstawowe zalety CSS możliwość zapanowania nad wyglądem strony bez ingerencji w jej strukturę pozwala na wzbogacenie wyglądu strony umożliwia scentralizowanie opisu wyglądu strony w jednym miejscu umożliwia tworzenie stylów dla grup stron CSS zabezpiecza przed konfliktem reguł (kaskada) zmniejsza rozmiary plików Szkielety tworzenia aplikacji 64

65 Łączenie CSS i HTML Istnieją trzy możliwości łączenia CSS i HTML: style wewnętrzne style osadzone style zewnętrzne style importowane Szkielety tworzenia aplikacji 65

66 Style wewnętrzne Do utworzenia stylu wewnętrznego służy w HTML u atrybut style, który można użyć zarówno wewnątrz znacznika body, jak i znaczników definiujących tekst, czy tabele, np.: <body style="font-family: tahoma, helvetica, verdana, arial; font-weight: normal; font-size: 10pt; text-align: justify;"> <p style="color:gray; padding:5px;"> Tekst </p> </body> Szkielety tworzenia aplikacji 66

67 Style osadzone Do utworzenia stylu osadzonego (embedded style sheet), służy znacznik style z nieodłącznym atrybutem type: <style type="text/css"> body {background:beige;} h1 {color:gray;} p {padding:5px;} </style> Szkielety tworzenia aplikacji 67

68 Style zewnętrzne Styl można opisać w zewnętrznym pliku o rozszerzeniu css i dołączyć do dokumentu HTML za pomocą znacznika <link> umieszconego wewnątrz nagłówka: <head> <title>tytuł strony</title> <link rel="stylesheet" type="text/css" href="style.css" /> </head> W zewnętrznym pliku znajduje się kod postaci: body {background:yellow;} h1 {text-align:center;} p {padding:5px;} Szkielety tworzenia aplikacji 68

69 Style importowane Styl można zaimportować z innego serwera: <head> <style url( </style> </head> Szkielety tworzenia aplikacji 69

70 Budowa reguł (1) Podstawowy opis elementu struktury w HTML u miał postać: <znacznik atrybut1="wartość" atrybut2="wartość2"> tekst </znacznik> W CSS, każda reguła składa się z selektora i deklaracji, zawierającej właściwości i ich wartości: selektor { właściwość1:wartość1; właściwość2:wartość2; } Szkielety tworzenia aplikacji 70

71 Budowa reguł (2) Selektor określa elementy struktury, do której reguła ma byś zastosowana,np.: h1 {text-align:left; color:blue;} Deklaracja znajdująca się w nawiasach klamrowych, składa się z właściwości, po której następuje dwukropek, oraz z wartości. Zapis deklaracji zakończony jest średnikiem. Wartość może być pojedynczym słowem kluczowym lub oddzieloną spacjami listą słów kluczowych (dozwoloną dla tej właściwości). Jeżeli w deklaracji użyto niepoprawnej właściwości, wtedy cała deklaracja jest ignorowana. Szkielety tworzenia aplikacji 71

72 Grupowanie selektorów Jeżeli chcemy nadać kilku elementom struktury te same właściwości, nie trzeba powtarzać kilkakrotnie tych samych zapisów zmieniając jedynie nazwę selektora. Wystarczy zapisać przed jedną deklaracją listę selektorów, oddzielonych przecinkami. selektor1, selektor2,..., selektorn { wł1:wart1; wł2:wart2; } Na przykład: body, table, th, td, h3, p {color:gray} Szkielety tworzenia aplikacji 72

73 Grupowanie deklaracji Jeden element może mieć zdefiniowanych wiele właściwości poprzez umieszczenie wewnątrz nawiasu klamrowego wielu deklaracji: selektor1 { wł1:wart1; wł2:wart2;...; włn:wartn; } Na przykład: body { font-family: tahoma, helvetica, verdana, arial; font-weight: normal; font-size: 10pt; text-align: justify; } Szkielety tworzenia aplikacji 73

74 Selektory klasy i identyfikatora (1) Oprócz selektorów elementów dokumentu istnieją jeszcze selektory klasy oraz selektory identyfikatora, które pozwalają na przypisanie stylów w sposób niezależny od elementów dokumentu. Aby używać selektorów klas, wewnątrz dokumentu HTML należy dodać atrybuty definiujące klasę: <znacznik class="nazwa_klasy">. Wewnątrz definicji stylów należy w takim wypadku użyć selektora: znacznik.nazwa_klasy {wlaściwość:wartość;} lub:.nazwa_klasy {wlaściwość:wartość;} Szkielety tworzenia aplikacji 74

75 Selektory klasy i identyfikatora (2) Aby używać selektorów identyfikatorów, wewnątrz dokumentu HTML należy dodać atrybut definiujący: <znacznik id="identyfikator">. Wewnątrz definicji stylów należy w takim wypadku użyć selektora: #identyfikator {wlaściwość:wartość;} Różnice pomiędzy selektorami klas i identyfikatorów: klasy mogą być przyporządkowane dowolnej liczbie elementów dany identyfikator powinien sie pojawić w dokumencie tylko raz identyfikator ma wyższy priorytet przy narzucaniu stylu Szkielety tworzenia aplikacji 75

76 Pseudoklasy i pseudoelementy Selektory pseudoklas i pseudoelementów służą do nadawania stylów elementom o zmiennych stanach, bądź nieistniejących w HTML u struktur. Podstawowe pseudoklasy w CSS to, klasy tyczące połączeń: a:link - styl łącza jeszcze nieodwiedzanego a:visited - styl łącza odwiedzonego a:active - styl łącza uaktywnionego Podstawowe pseudoelementy w CSS to: :first-letter - określa odrębny styl dla pierwszej litery elementu struktury :first-line - określa odrębny styl dla pierwszej linii elementu struktury Szkielety tworzenia aplikacji 76

77 Drzewo struktur HTML Szkielety tworzenia aplikacji 77

78 Selektory kontekstowe Selektory kontekstowe umożliwiają zdefiniowanie stylu, dla odpowiedniego elementu wewnątrz drzewa dokumentu HTML. ul li ul li {color:gray;} Selektor kontekstowy to kompozycja dwóch lub więcej selektorów elementów rozgraniczonych spacjami. Każda spacja oznacza zagnieżdżenie. Szkielety tworzenia aplikacji 78

79 Dziedziczenie i wagi Elementy zagnieżdżone dziedziczą styl, po elemencie nadrzędnym. Niewszystkie właściwości są dziedziczone (marginesy, odstępy od ramek, tło, obramowanie). W wypadku powtarzających się definicji stylu dla danego elementu, CSS zabezpiecza się przed konfliktami za pomocą wag nadawanych poszczególnym regułom: selektor {właściwość:wartość;} /* 1 */ selektor1 selektor2 {właściwość:wartość;} /* 2 */.klasa {właściwość:wartość;} /* 10 */ selektor.klasa {właściwość:wartość;} /* 11 */ selektor1.klasa1 selektor2.klasa2 {właściwość:wartość;} /* 22 */ #identyfikator {właściwość:wartość;} /* 100 */ Szkielety tworzenia aplikacji 79

80 Kaskada Algorytm kaskady: Znajdź wszystkie deklaracje zawierające selektory odpowiadające danemu elementowi. Posortuj znalezione deklaracje według wag. Posortuj znalezione deklaracje ze względu na kolejność występowania (uznaje się, że deklaracje z plików zewnętrznych są przesłaniane stylami osadzonymi, a te stylami wewnętrznymi). Zawsze najważniejszy jest styl stojący na końcu. Szkielety tworzenia aplikacji 80

81 Architektura aplikacji Django Szkielety tworzenia aplikacji 81

82 Składniki aplikacji Django URLconf - odpowiedzialne za przetwarzanie adresów URL na widoki, Widoki - funkcje przetwarzające żadanie HttpRequest i zwracające odpowiedź HttpResponse, Middleware (warstwa pośrednicząca) - umożliwia lekkie, niskopoziomowe przetwarzanie wejścia-wyjścia Django (żądań, odpowiedzi, widoki), Szablony - plik tekstowy zawierający zazwyczaj kod HTML oraz tagi (kontrola logiki szablonu i przekształcanie treści), Modele - źródło danych aplikacji, zazwyczaj jest powiązane z tabelami bazy danych, ORM - odpowiedzialne za przekształcenie postaci obiektowej na postać relacyjną. Szkielety tworzenia aplikacji 82

83 URLconf I W celu zaprojektowania URL-i dla aplikacji tworzy się moduł Pythona nieformalnie zwany URLconf (konfiguracja URL). Wspomniany moduł jest zaimplementowany w czystym Pythonie jest prostym mapowaniem pomiędzy wzorcami adresów URL (zapisanymi jako wyrażenia regularne) a Pythonowymi funkcjami wywołań zwrotnych (widoków). Mapowanie to może być, w zależności od potrzeb krótkie lub długie. Może odwoływać się do innych mapowań i ze względu na to że jest modułem Pythona może być tworzone dynamicznie. Szkielety tworzenia aplikacji 83

84 URLconf II Sposób przetwarzania żądania ze strony przez Django: 1 Django określa moduł z głównym URLconf. Zazwyczaj jest określony przez zawartość zmiennej ROOT_URLCONF, czasem jest też określane przez atrybut urlconf obiektu nadchodzącego żadania HttpRequest (ustawione przez warstwę pośrednią), jej zawartość będzie użyta zamiast zmiennej ROOT_URLCONF. 2 Django ładuje ten moduł i szuka zmiennej urlpatterns. Powinna to być lista Pythona, w formacie zwróconym przez funkcję django.conf.urls.patterns(). 3 Django przechodzi po kolei przez każdy wzorzec URL i kończy przy pierwszym dopasowaniu żądanego adresu URL. Szkielety tworzenia aplikacji 84

85 URLconf III 4 Po tym jak jedno z wyrażeń regularnych dopasowuje URL, Django importuje i wywołuje dany widok, jest nim zwykła funkcja Pythona. Widok otrzymuje obiekt HttpRequest jako swój pierwszy argument natomiast resztą argumentów są wartości przechwycone przez wyrażenie regularne. 5 Jeśli żadne z wyrażeń regularnych nie dopasowało URL-a lub wywoływany jest wyjątek przy jednym z punktów tego procesu, Django wywołuje odpowiedni widok obsługi błędów. Szkielety tworzenia aplikacji 85

86 URLconf IV from django.conf.urls import patterns, url, include urlpatterns = patterns(, (r ^articles/2003/$, news.views.special_case_2003 ), (r ^articles/(\d{4})/$, news.views.year_archive ), (r ^articles/(\d{4})/(\d{2})/$, news.views.month_archive ), (r ^articles/(\d{4})/(\d{2})/(\d+)/$, news.views.article_detail ), ) /articles/2005/03/ dopasowanie do trzeciego wzorca. /articles/2005/3/ brak dopasowania (wymagane dwie cyfry miesiąca). /articles/2003/ dopasowanie do pierwszego wzorca. /articles/2003 brak dopasowania (brak kończącego /). /articles/2003/03/03/ dopasowanie do ostatniego wzorca. Szkielety tworzenia aplikacji 86

87 Grupy nazwane I Wcześniejszy przykład używał nienazwanych grup wyrażeń regularnych (za pomocą nawiasów) do przechwycenia części URL-a i przekazania ich jako argumentów określonych pozycją do widoku. W bardziej zaawansowanych zastosowaniach jest zazwyczaj konieczne używanie nazwanych grup wyrażeń regularnych do przechwytywania części URL-a i przekazywania ich do widoku jako argumentów kluczowych. Składnia Pythona dla nazwanych wyrażeń regularnych - (?P<name>pattern) - name jest nazwą grupy a wzorzec jest używany do dopasowania. Szkielety tworzenia aplikacji 87

88 Grupy nazwane II urlpatterns = patterns(, (r ^articles/2003/$, news.views.special_case_2003 ), (r ^articles/(?p<year>\d{4})/$, news.views.year_archive ), (r ^articles/(?p<year>\d{4})/(?p<month>\d{2})/$, news.views.month_archive ), (r ^articles/(?p<year>\d{4})/(?p<month>\d{2})/(?p<day>\d{2})/$, news.views.article_detail ), ) Żądanie /articles/2005/03/ wywoła funkcję news.views.month_archive(request, year= 2005, month= 03 ) zamiast jak w poprzednim przypadku news.views.month_archive(request, 2005, 03 ). Szkielety tworzenia aplikacji 88

89 Funkcje widoku I Widok (funkcja widoku) jest po prostu funkcją, która przyjmuje żądanie Http i zwraca odpowiedź Http. Odpowiedzią może być w zasadzie dowolna: np. strona Html, przekierowanie do innego adresu, błąd 404, dokument XML, obrazek itd. Widok zawiera całą logikę konieczną do przetworzenia żądania i zwrócenia odpowiedzi. Kod odpowiedzialny za implementację widoku może co prawda znajdować się w dowolnym miejscu (jeśli tylko znajduje się na ścieżkach przeszukiwań Pythona), zazwyczaj jednak przestrzega się konwencji umieszczając widoki w pliku views.py znajdującym się w katalogu projektu lub aplikacji. Szkielety tworzenia aplikacji 89

90 Funkcje widoku II from django.http import HttpResponse def my_view(request): #... if foo: return HttpResponseNotFound( <h1>not found</h1> ) else: return HttpResponse( <h1>page was found</h1> Szkielety tworzenia aplikacji 90

91 Widoki generyczne I Tworzenie aplikacji internetowych jest monotonne wymaga wielokrotnego zapisu pewnych szablonów. Django dostarcza rozwiązań nie tylko na poziomie modelu i szablonu, lecz również na poziomie widoku. Widoki generyczne Django zostały zaprojektowane w celu ułatwienia tworzenia powtarzalnych zadań - dostarczają pewnych pewnych idiomów i wzorców na podstawie tworzonych wcześniej widoków. Wprowadzają warstwę abstrakcji przez co możliwy jest szybki zapis powtarzalnych widoków bez potrzeby zapisu dużej ilości kodu. Można rozpoznać powszechnie używane zadania jak wyświetlanie listy obiektów i zapisać kod wyświetlający listę dowolnych obiektów. Wymagany model może być przekazywany jako dodatkowy argument dla URLconf. Szkielety tworzenia aplikacji 91

92 Widoki generyczne II Django zapewnia łatwy do wykorzystania kod widoków: wykonujących nieskomplikowane powszechnie wykonywane zadania: przekierowanie do różnych stron i renderowanie wybranego szablonu. wyświetlających listę powiązanych ze sobą obiektów oraz stron zawierających istotne szczegóły dla pojedynczych obiektów (lista zamówień klientów i zamówienie dla określonego klienta). prezentujących oparte na dacie obiekty w postaci stron zawierających ustalone działania w postaci wykazów rok/miesiąc/dzień, and stron zawierających ostatnie działania - latest (np. archiwum bloga). umożliwiających użytkownikom tworzenie, aktualizacje i niszczenie obiektów z i bez autoryzacji. Szkielety tworzenia aplikacji 92

93 Widoki generyczne III Najważniejsze widoki generyczne: View - klasa bazowa dla wszystkich widoków, TemplateView - renderuje określony szablon (najczęściej statyczne widoki), RedirectView - przekierowanie do określonej strony, DetailView - strona reprezentująca pojedynczy obiekt, ListView - reprezentacja listy obiektów, FormView - widok, który wyświetla formę, Szkielety tworzenia aplikacji 93

94 Widoki generyczne IV {Create,Update,Delete}View - formy do tworzenia, edycji i niszczenia obiektów, ArchiveIndexView - strona najwyższego poziomu prezentująca najnowsze obiekty {Year,Month,Week,Day,Today}ArchiveView - umożliwia wyświetlenie obiektów powiązanych z datą. DateDetailView - pojedynczy obiekt powiązany z datą. Szkielety tworzenia aplikacji 94

95 Widoki generyczne V Przykład wykorzystujący dziedziczenie: from django.views.generic import TemplateView class AboutView(TemplateView): template_name = "about.html" Odziedziczony atrybut template_name przechowuje nazwę (ze ścieżką) szablonu jaki ma zostać użyty (w przykładzie w katalogu templates został stworzony katalog o nazwie about.html) W urls.py dodaje się import: from book.views import AboutView Natomiast do reguł mapujących URL-e: (r ^about/$, AboutView.as_view()), Szkielety tworzenia aplikacji 95

96 Widoki generyczne VI Po odwołaniu do adresu /about/ zostanie wyświetlona strona z użyciem szablonu about.html. Można korzystać także bezpośrednio w urls.py przy mapowaniu linków na widoki. Wystarczy że zaimportować TemplateView i użyć: (r ^about2/$, TemplateView.as_view(template_name="about.html")), Szkielety tworzenia aplikacji 96

97 Idea szablonów Umieszczanie kodu HTML w widokach nie jest dobrym pomysłem - dowolna zmiana projektu strony wymaga zmiany w kodzie Pythona Tworzenie kodu Pythona i projektowanie wyglądu strony w HTML to dwie różne dyscypliny, więc większość profesjonalnych zespołów rozdziela te zadania na różne osoby (czasem nawet działy) Praca posuwa się znacznie sprawniej, jeśli programiści mogą pracować nad kodem Pythona, a projektanci nad szablonami. Szkielety tworzenia aplikacji 97

98 Filozofia i ograniczenia I Logikę biznesową należy rozdzielić od logiki prezentacyjnej. Programiści Django widzą system szablonów jako narzędzie sterujące prezentacją i związaną z tym logiką - to wszystko. System szablonów nie powinien obsługiwać funkcjonalności wychodzącej poza ten prosty cel. Nie można wywołać kodu Pythona bezpośrednio z szablonów. Całe "programowanie" ogranicza się w zasadzie do tego, co potrafią znaczniki szablonu. Choć można napisać własny znacznik, który wykonuje dowolne zadanie, domyślnie szablony Django nie dopuszczają wykonania dowolnego kodu Pythona. Szkielety tworzenia aplikacji 98

99 Filozofia i ograniczenia II Składnię należy oddzielić od HTML/XML. Choć system szablonów Django służy przede wszystkim do generowania kodu HTML, nic nie stoi na przeszkodzie, by stosować go dla dowolnych formatów innych niż HTML, na przykład zwykłego tekstu. Niektóre inne języki szablonów bazują na XML, umieszczając całą logikę szablonu w znacznikach i atrybutach XML, ale Django celowo unika tego ograniczenia. Wymuszenie korzystania z XML wprowadza cały wachlarz prostych, ludzkich pomyłek i trudnych w zrozumieniu komunikatów błędów. Stosowanie systemu przetwarzania XML wprowadza również zbyt duży narzut związany z obróbką i renderingiem szablonu. Szkielety tworzenia aplikacji 99

100 Filozofia i ograniczenia III Zakłada się, że projektanci znają kod HTML. System szablonów nie został zaprojektowany w taki sposób, by wyglądał ładnie w edytorach WYSIWYG takich jak Dreamweaver. To zbyt duże ograniczenie, które uniemożliwiłoby powstanie tak przyjaznej składni. Django oczekuje, że autorzy szablonów będą potrafili korzystać bezpośrednio z języka HTML. Zakłada się, że projektanci nie są programistami języka Python. Autorzy systemu szablonów są przekonani, że większość szablonów stron WWW piszą projektanci, a nie programiści, więc nie należy zakładać znajomości języka Python. Szkielety tworzenia aplikacji 100

101 Filozofia i ograniczenia IV System stara się zaspokoić sposób pracy małych zespołów, w których to szablony są tworzące przez programistów języka Python. Oferuje sposoby rozszerzenia składni systemu przez pisanie czystego kodu Pythona. Celem nie jest wymyślanie języka programowania. Celem jest zapewnienie wystarczającej swobody przez dostarczenie pętli i warunków, by możliwe było podejmowanie decyzji związanych z prezentacją danych. Szkielety tworzenia aplikacji 101

102 Podstawy systemu szablonów Szablon Django to łańcuch tekstowy mający na celu odseparowanie prezentacji dokumentu od jego danych. Szablon definiuje miejsca wstawień danych oraz zawiera prostą logikę (znaczniki szablonu), które określając sposób wyświetlania dokumentu. Najczęściej szablony używa się do generowania kodu HTML, ale szablony Django doskonale nadają się do generowania danych w dowolnym formacie tekstowym. Szkielety tworzenia aplikacji 102

103 Przykład szablonu I {% extends "base_generic.html" %} {% block title %}{{ section.title }}{% endblock %} {% block content %} <h1>{{ section.title }}</h1> {% for story in story_list %} <h2> <a href="{{ story.get_absolute_url }}"> {{ story.headline upper }} </a> </h2> <p>{{ story.tease truncatewords:"100" }}</p> {% endfor %} {% endblock %} Szkielety tworzenia aplikacji 103

104 Korzystanie z systemu szablonów I Utwórz obiekt Template, przekazując treść szablonu jako tekst. Wywołaj metodę render() obiektu Template wraz z zestawem zmiennych zwanym kontekstem. Wynikiem jest w pełni zrenderowany kod ze wszystkimi zmiennymi i znacznikami szablonowymi wyliczonymi i wstawionymi zgodnie z zawartością kontekstu. Szkielety tworzenia aplikacji 104

105 Korzystanie z systemu szablonów II Kod: >>> from django import template >>> t = template.template("nazywam się {{ name }}.") >>> c = template.context({ name : Adrian }) >>> print t.render(c) Nazywam się Adrian. >>> c = template.context({ name : Fred }) >>> print t.render(c) Nazywam się Fred. Najprostszym sposobem utworzenia obiektu typu Template jest bezpośrednie użycie jego klasy. Klasa Template znajduje się w module django.template. Konstruktor przyjmuje jeden argument, którym jest nieprzetworzony kod szablonu. Szkielety tworzenia aplikacji 105

106 Błędy szablonów System zgłasza wyjątek TemplateSyntaxError dla każdego z podanych niżej przypadków: niepoprawnych znaczników, niepoprawnych argumentów poprawnych znaczników, błędnych filtrów, niepoprawnych argumentów poprawnych filtrów, złej składni szablonu, niedomkniętych znaczników (dla znaczników wymagających zamknięcia). Szkielety tworzenia aplikacji 106

107 Filtry i znaczniki szablonów I {% if %} analizuje zmienną i jeśli jej wartość odpowiada wartości prawdy (czyli istnieje, nie jest pusta i nie jest fałszem), system wyświetli wszystko między {% if %} i {% endif %}. Oto przykład: {% if today_is_weekend %} <p>ciesz się weekendem!</p> {% else %} <p>do roboty!</p> {% endif %} {% for %} umożliwia przejście przez każdy element pewnej sekwencji. Podobnie jak w Pythonie, stosowaną składnią jest for X in Y. W każdym cyklu pętli system szablonów będzie renderował wszystko, co znajdzie się między znacznikami {% for %} i {% endfor %}. Szkielety tworzenia aplikacji 107

108 Filtry i znaczniki szablonów II <ul> {% for athlete in athlete_list %} <li>{{ athlete.name }}</li> {% endfor %} </ul> {% ifequal %} umozliwia porównanie dwóch wartości {% ifequal user currentuser %} <h1>witaj!</h1> {% endifequal %} Komentarze wstawiamy w znacznikach {# #} Komentarze można również umieszczać pomiędzy tagami {% comment %}Treść komentarza{% endcomment %} Szkielety tworzenia aplikacji 108

109 Filtry i znaczniki szablonów III Filtry to sposób na zmianę zawartości zmiennej przed jej wyświetleniem (wykorzystuje się w tym celu znak pionowej kreski) zmiana zmiennej name za pomocą filtru lower {{ name lower }} filtry da się łączyć w łańcuchy (wynik działania filtru jest przekazywany do następnego w kolejności filtru) {{ my_list first upper }} filtry mogą również przyjmować parametry {{ bio truncatewords:"30" }} Szkielety tworzenia aplikacji 109

110 Filtry i znaczniki szablonów IV Ważniejsze filtry: safe - zapobiega kodowaniu tagów HTML add - dodaje do zmiennej podaną jako argument wartość (zmienna add:"liczba"), cut - usuwa wszystkie wystąpienia podanego łańcucha w zmiennej (zmienna cut:"łańcuch"), default - jeżeli zmienna może być interpretowana jako fałsz, wykorzystuje się podaną jako argument wartość, escape - zamienia < > oraz cudzysłowy na format Html, first - zwraca pierwszy element z listy, length - zwraca długość przekazywanego do niego elementu (np. listy, łańcucha znaków), linebreaks - zamienia przejścia do nowej linii na tagi p i br, lower - zamienia wszystkie litery na małe, Szkielety tworzenia aplikacji 110

111 Filtry i znaczniki szablonów V pluralize - zwraca przyrostek jeżeli wartość nie jest równa 1 (domyślnie dodaje s) Masz {{ n_m }} wiadomoś{{ n_m pluralize:"ć,ci" }}, removetags - usuwa tagi X/HTML ze zmiennej (tagi są podane jako argument oddzielone spacjami), striptags - usuwa wszystkie tagi X/HTML, truncatewords - przycina łańcuch do łańcucha zawierającego określoną liczbę słów (wycięte słowa są zastępowane...), unordered_list - przerabia listę na listę li/ul, upper - wszystkie litery zmieniane są na duże, urlize - zamienia linki w zwykłym tekście na odnośniki, które można kliknąć, wordcount - zwraca liczbę słów, wordwrap - łamie wiersze przy podanej liczbie znaków. Szkielety tworzenia aplikacji 111

112 Dziedziczenie szablonów I Dziedziczenie szablonów umożliwia tworzenia szkieletowych szablonów, które zawierają wszystkie wspólne elementy tworzonej aplikacji i definiują bloki które są przesłaniane przez pochodne szablony. Szablon bazowy base.html: <!DOCTYPE html> <html lang="en"> <head> <link rel="stylesheet" href="style.css" /> <title> {% block title %}My amazing site{% endblock %} </title> </head> Szkielety tworzenia aplikacji 112

113 Dziedziczenie szablonów II <body> <div id="sidebar"> {% block sidebar %} <ul> <li><a href="/">home</a></li> <li><a href="/blog/">blog</a></li> </ul> {% endblock %} </div> <div id="content"> {% block content %}{% endblock %} </div> </body> </html> Szkielety tworzenia aplikacji 113

114 Dziedziczenie szablonów III Szablon pochodny: {% extends "base.html" %} {% block title %}My amazing blog{% endblock %} {% block content %} {% for entry in blog_entries %} <h2>{{ entry.title }}</h2> <p>{{ entry.body }}</p> {% endfor %} {% endblock %} Szkielety tworzenia aplikacji 114

115 Korzystanie z szablonów w widokach I Szablon z wykorzystaniem metod Pythona: from django.http import HttpResponse import datetime def current_datetime(request): now = datetime.datetime.now() html = "<html><body>teraz jest %s. </body></html>" % now return HttpResponse(html) Szkielety tworzenia aplikacji 115

116 Korzystanie z szablonów w widokach II Szablon Django (Template): from django.template import Template, Context from django.http import HttpResponse import datetime def current_datetime(request): now = datetime.datetime.now() t = Template("<html><body> Teraz jest {{ current_date }}. </body></html>") html = t.render(context({ current_date : now})) return HttpResponse(html) Szkielety tworzenia aplikacji 116

117 Korzystanie z szablonów w widokach III Szablon z pliku: from django.template import Template, Context from django.http import HttpResponse import datetime def current_datetime(request): now = datetime.datetime.now() # Prosty sposób użycia szablonu z systemu plików. fp = open( /home/ja/templates/mytemplate.html ) t = Template(fp.read()) fp.close() html = t.render(context({ current_date : now})) return HttpResponse(html) Szkielety tworzenia aplikacji 117

118 Wczytywanie szablonów I konfiguracja ścieżki szablonów w pliku settings.py TEMPLATE_DIRS = ( /home/ja/pracuj/templates, ) można również skorzystać z katalogów domyślnych - templates Szkielety tworzenia aplikacji 118

119 Wczytywanie szablonów II zmiana pliku widoku: from django.template.loader import get_template from django.template import Context from django.http import HttpResponse import datetime def current_datetime(request): now = datetime.datetime.now() t = get_template( current_datetime.html ) html = t.render(context({ current_date : now})) return HttpResponse(html) Szkielety tworzenia aplikacji 119

120 render_to_response() Django zapewnia skrót, który pozwala wczytać szablon, zrenderować go i zwrócić obiekt HTTPResponse - wszystko to w jednym wierszu kodu. from django.shortcuts import render_to_response import datetime def current_datetime(request): now = datetime.datetime.now() return render_to_response( current_datetime.html, { current_date : now} ) Szkielety tworzenia aplikacji 120

121 Model I Model jest pojedynczym źródłem danych. Zawiera pola składowe i informacje w jaki sposób składować dane. Najczęściej z każdym modelem jest powiązana tabela bazy danych. Każdy model jest podklasą klasy django.db.models.model. Każdy atrybut jest związany z odpowiednim polem tabeli. Django dostarcza automatycznie wygenerowanego API pozwalającego na dostęp do bazy danych. Szkielety tworzenia aplikacji 121

122 Model II Przykład modelu from django.db import models class Muzyk(models.Model): imie = models.charfield(max_length=50) nazwisko = models.charfield(max_length=50) instrument = models.charfield(max_length=100) class Album(models.Model): artysta = models.foreignkey(muzyk) nazwa = models.charfield(max_length=100) data_wydania = models.datefield() liczba_gwiazdek = models.integerfield() Szkielety tworzenia aplikacji 122

123 Typy pól składowych I AutoField BigIntegerField BooleanField CharField CommaSeparatedIntegerField DateField DateTimeField DecimalField Field FileField FieldFile Szkielety tworzenia aplikacji 123 FilePathField FloatField ImageField IntegerField IPAddressField NullBooleanField PositiveIntegerField PositiveSmallIntegerField SlugField SmallIntegerField TextField TimeField URLField

124 Opcje pól składowych I null - jeśli jest ustawione na True, Django umożliwi przechowywanie wartości pustych jako NULL (wartość domyślna False), blank - jeżeli jest ustawione na True pole może być pominięte w trakcie wprowadzania wartości (wartość domyślna False); jest to wartość różna od null, null jest związane z relacyjnymi bazami danych, natomiast blank jest związane z sposobem walidacji, choices - lista lub krotka zawierająca dwuelementowe krotki używane do wyboru danych dla tego pola; jeśli jest ustawione administrator może użyć listy rozwijanej zamiast standardowych pól tekstowych, umożliwia ograniczenie wyboru wartości. Szkielety tworzenia aplikacji 124

125 Opcje pól składowych II Pierwszym elementem w krotce jest wartość jaka będzie zachowana w bazie danych, drugim elementem krotki jest element jaki będzie wyświetlony w interfejsie administratora lub w ModelChoiceField. Wyświetlana wartość pola wybieralnego może być osiągnięta za pomocą metody get_foo_display() (FOO powinno być zastąpione nazwą pola składowego). Na przykład: from django.db import models class Person(models.Model): GCH = ( (u M, u Mężczyzna ), (u K, u Kobieta ), ) name = models.charfield(max_length=60) gender = models.charfield(max_length=2, choices=gch) Szkielety tworzenia aplikacji 125

126 Opcje pól składowych III >>> p = Person(name="Fred", gender="m") >>> p.save() >>> p.gender u M >>> p.get_gender_display() u Mężczyzna default - wartość domyślna pola, help_text - dodatkowa pomoc wyświetlana dla pola w interfejsie administracyjnym, primary_key - jeśli jest ustawiona na True to pole jest traktowane jako klucz główny modelu; gdy żadne pole nie jest ustawione jako klucz główny, Django tworzy taki klucz w sposób automatyczny, unique - jeśli jest ustawiona na True dane pole musi być unikalne dla całej tabeli. Szkielety tworzenia aplikacji 126

127 Relacje pomiędzy modelami I Relacje wiele do jednego - są realizowane za pomocą klasy django.db.models.foreignkey. Konstruktor klasy ForeignKey wymagania podania klasy z którą podany model jest powiązany. class Producent(models.Model): #... class Samochod(models.Model): producent = models.foreignkey(producent) #... Można tworzyć relacje rekurencyjne (obiekt z relacja wiele do jednego do samego siebie - models.foreignkey( self )) i relacje do modeli, które nie są jeszcze zdefiniowane models.foreignkey( Producent ). Szkielety tworzenia aplikacji 127

128 Relacje pomiędzy modelami II Relacje wiele do wielu - są realizowane za pomocą klasy ManyToManyField. Konstuktor klasy ManyToManyField podania klasy z którą model jest powiązany class Dodatek(models.Model): #... class Pizza(models.Model): #... dodatki = models.manytomanyfield(dodatek) Można tworzyć relacje rekurencyjne i relacje z modelami, które jeszcze nie zostały zdefiniowane. Nie ma znaczenia, który model posiada pole ManyToManyField powinno być użyte w jednym wybranym modelu. Szkielety tworzenia aplikacji 128

129 Relacje pomiędzy modelami III Możliwe jest również utworzenie klasy zarządzającej relacją wiele do wielu dla bardziej skomplikowanych przypadków. from models import ManyToManyField class Person(models.Model): name = models.charfield(max_length=128) def unicode (self): return self.name class Group(models.Model): name = models.charfield(max_length=128) members = ManyToManyField(Person, through= Member ) def unicode (self): return self.name Szkielety tworzenia aplikacji 129

130 Relacje pomiędzy modelami IV class Member(models.Model): person = models.foreignkey(person) group = models.foreignkey(group) date_joined = models.datefield() invite_reason = models.charfield(max_length=64) Relacja jeden do jednego - są realizowane za pomocą klasy OneToOneField. Są najbardziej użyteczne dla kluczy głównych obiektów, które są rozszerzane w jakiś sposób przez inny obiekt. Konstruktor klasy OneToOneField wymaga podania klasy z którą podany model jest powiązany. Można tworzyć relacje rekurencyjne i relacje z modelami, które jeszcze nie zostały zdefiniowane. Szkielety tworzenia aplikacji 130

131 Klasa wewnętrzna Meta I Django pozwala używać dodatkowych metainformacji o modelu, są one definiowane z wykorzystaniem klasy wewnętrznej modelu o nazwie Meta. class Ox(models.Model): horn_length = models.integerfield() class Meta: ordering = ["horn_length"] verbose_name = "wół" verbose_name_plural = "woły" Szkielety tworzenia aplikacji 131

132 Klasa wewnętrzna Meta II Najważniejszymi polami są: db_table - nazwa tabeli (jeśli potrzebna jest nazwa różna od standardowej), order_with_respect_to - określa sortowanie względem zależnego pola, ordering - domyślny sposób porządkowania obiektów permissions - określa dodatkowe (oprócz standardowych add, delete, change) uprawnienia dla obiektów danego modelu, verbose_name - czytelna dla człowieka nazwa pojedynczego obiektu, verbose_name_plural - czytelna dla człowieka nazwa wielu obiektów. Szkielety tworzenia aplikacji 132

133 Metody modeli I full_clean(exclude=none) - wywołuje metody w kolejności clean_fields(), clean() i validate_unique() zgłasza wyjątek ValidationError jeśli, w którykolwiek z etapów zakończy się błędem, clean_fields(exclude=none) - metoda waliduje wszystkie pola modelu (wywołuje w razie niepowodzenia wyjątek ValidationError), validate_unique(exclude=none) - metoda podobna w działaniu do clean_fields() przy czym waliduje wszystkie ograniczenia modelu jako całości zamiast pojedynczych pól, clean() - metoda ta powinna zostać przesłonięta dla wprowadzenia własnej walidacji i modyfikacji atrybutów modelu Szkielety tworzenia aplikacji 133

134 Metody modeli II def clean(self): if self.status == draft and self.pub_date is not None: raise ValidationError( Niedozwolone pole dla wersji roboczej ) if self.status == published and self.pub_date is None: self.pub_date = datetime.datetime.now() save() - zapisuje obiekt do bazy danych, może być przesłonięta, autoinkrementacja kluczów głównych, przeprowadzona dopiero po pierwszym użyciu metody save(), właściwość pk - właściwość, która posiada każdy model niezależnie od tego czy klucz główny został zdefiniowany samodzielnie czy został wprowadzony przez Django, jest aliasem do klucza głównego, delete([using=default_db_alias]) - powoduje wywołanie komendy SQL DELETE, niszczy tylko obiekt w bazie danych, można ją przesłonić w własnym modelu, Szkielety tworzenia aplikacji 134

135 Metody modeli III unicode () wywoływana za każdym razem, gdy wywoływane jest z obiektem jako argumentem unicode(). Django używa unicode(obj) (lub związanej z nią str(obj)) w wielu miejscach np. w interfejsie administracyjnym i jako wartość wstawiana do szablonu, gdy konieczne jest wyświetlenie zawartości obiektu. get_absolute_url() powiadamia Django jak ma wyznaczać adresy URL dla obiektów, jest użyteczne dla szablonów def get_absolute_url(self): return "/people/%i/" % self.id Zamiast <a href="/people/{{ obj.id }}/">{{ obj.name }}</a> lepiej użyć: <a href="{{ obj.get_absolute_url }}">{{ obj.name }}</a> Szkielety tworzenia aplikacji 135

136 Metody modeli IV get_foo_display() - dostępna dla atrybutów wybieralnych, funkcja reverse() - pobiera nazwę wzorca URL i listę pozycyjnych lub nazwanych argumentów i tworzy pełny, poprawny adres URL. (r ^people/(\d+)/$, people.views.details ), from django.core.urlresolvers import reverse def get_absolute_url(self): return reverse( people.views.details, args=[str(self.id)]) Szkielety tworzenia aplikacji 136

137 Metody modeli V Podobnie: (r /archive/\ (?P<year>\d{4})/(?P<month>\d{2})/(?P<day>\d{2})/$, archive_view) def get_absolute_url(self): return reverse( archive_view, kwargs={ year : self.created.year, month : self.created.strftime( %m ), day : self.created.strftime( %d )}) Szkielety tworzenia aplikacji 137

138 QuerySet I Obiekty QuerySet są tworzone przez metody (all, filter, exclude, get) klasy Manager w celu uzyskiwania obiektów z bazy danych. Obiekty te reprezentują kolekcje obiektów. Mogą zawierać filtry, które zawężają wybór pod względem podanych parametrów. W terminologii SQL reprezentują instrukcje SELECT natomiast filtry są związane z klauzulami takimi jak WHERE lub LIMIT. Nie wykonują od razu zapytań, wykonują je tylko wtedy gdy jest to wymagane np. przy pierwszym przejściu przez elementy objęte zapytaniem. Szkielety tworzenia aplikacji 138

139 QuerySet II >>> Blog.objects <django.db.models.manager.manager object at...> >>> b = Blog(name= Foo, tagline= Bar ) >>> b.objects Traceback:... AttributeError: "Manager isn t accessible via Blog instances." Ostatnia linijka kończy się błędem, gdyż obiekt managera jest dostępny za pomocą klasy modelu a nie instancji modelu, wymusza to odseparowanie operacji na tabeli od operacji na rekordzie. Metody Managera: Szkielety tworzenia aplikacji 139

140 QuerySet III all() - zwraca QuerySet zawierający wszystkie obiekty z tabeli >>> all_entries = Entry.objects.all() filter(**kwargs) - uzyskuje QuerySet, którego obiekty spełniają podane jako argumenty kryterium; Entry.objects.filter(pub_date year=2006) exclude(**kwargs) - uzyskuje QuerySet, którego obiekty nie spełniają podane jako argumenty kryterium, można wywołania tej metody i poprzedniej łączyć w łańcuchy wywołań; Szkielety tworzenia aplikacji 140

141 QuerySet IV >>> Entry.objects.filter(... headline startswith= What... ).exclude(... pub_date gte=datetime.now()... ).filter(... pub_date gte=datetime(2005, 1, 1)... ) get() - pozwala na uzyskiwanie pojedynczego obiektu jako wyniku zapytania (tylko jednego!) >>> one_entry = Entry.objects.get(pk=1) Szkielety tworzenia aplikacji 141

142 Formularze HTML W HTML formularze są kolekcją elementów umieszczonych w znaczniku <form>, które umożliwiają użytkownikowi wpisywanie tekstu, wybór opcji, przekształcenie obiektów. Wprowadzane dane są zazwyczaj przesyłane do serwera. Wprowadzanie danych jest oparte o elementy <input>. Zarówno formularz, jak i elementy <input> muszą specyfikować dwie rzeczy: adres, gdzie powinny być przekazane dane użytkownika, metodę HTTP, jaka powinna być użyta do przekazania danych. Szkielety tworzenia aplikacji 142

143 Rola Django w formularzach Obsługa formularzy jest skomplikowana, na szczęście Django pozwala w dużej mierze na uproszczenie i zautomatyzowanie tej pracy. Django obsługuje trzy różne części pracy formularzy. Są to: przygotowanie danych gotowych do odtwarzania, tworzenie formularzy HTML dla danych, odbieranie i przetwarzanie wysłanych danych przez klienta. Szkielety tworzenia aplikacji 143

144 Klasa Form Podstawą systemu komponentów jest klasa Form. Klasy modeli opisują logiczną strukturę obiektów, ich zachowanie, natomiast klasa Form opisuje formularze. Klasy formularzy mapują pola do elementów <input>. Klasa ModelForm odwzorowuje pola modelu do elementów <input>. Pola formularza są reprezentowane przez klasy, które zarządzają danymi formularzy i sprawdzają ich poprawność, gdy formularz jest wysyłany. Pola formularzy są prezentowane użytkownikowi w przeglądarce jako widgety HTML. Każdy typ pola ma odpowiednią domyślną klasę widgetu. Szkielety tworzenia aplikacji 144

145 Tworzenie formularzy w Django I Szablon formularza: <form action="/your-name/" method="post"> <label for="your_name">twoje imie: </label> <input id="your_name" type="text" name="your_name" value="{{ current_name }}"> <input type="submit" value="ok"> </form> Szkielety tworzenia aplikacji 145

146 Tworzenie formularzy w Django II Klasę formularza: from django import forms c l a s s NameForm ( forms. Form ) : your_name = forms. C h a r F i e l d ( l a b e l= Twoje i m i e, max_length =100) Obiekt formularza jest renderowany do postaci: <label for="your_name">your name: </label> <input id="your_name" type="text" name="your_name" maxlength="100"> Szkielety tworzenia aplikacji 146

147 Tworzenie formularzy w Django III Nie wstawiono znacznika <form> i przycisku pozwalającego na wysłanie formularza - trzeba je samodzielnie wstawić do szablonu formularza. Ostatecznie formularz przyjmie postać: <form action="/your-name/" method="post"> {% csrf_token %} {{ form }} <input type="submit" value="submit" /> </form> Token csrf_token jest wykorzystywany do ochrony przed cross site request forgery. Szkielety tworzenia aplikacji 147

148 Widok formularza I Dane formularza wysyłane do strony Django są przetwarzane przez widok, zazwyczaj ten sam, który zamieścił formularza. from django. s h o r t c u t s import r e n d e r from django. h t t p import H t t p R e s p o n s e R e d i r e c t d e f get_name ( r e q u e s t ) : # Je ż e l i n a s t ą p i ł o ż ą d a n i e POST, n a l e ż y p r z e t w o r z y ć dane. i f r e q u e s t. method == POST : # Tworzenie i n s t a n c j i formy # i wype ł n i e n i e j e j danymi z ż ą d a n i a : form = NameForm ( r e q u e s t.post) # Sprawdzenie czy f o r m u l a r z z a w i e r a poprawne dane i f form. i s _ v a l i d ( ) : # Je ż e l i to wymagane p r z e t w a r z a n e s ą dane form. cleaned_data Szkielety tworzenia aplikacji 148

149 Widok formularza II #... # P r z e k i e r o w a n i e do nowego URL : r e t u r n H t t p R e s p o n s e R e d i r e c t ( / thanks / ) # Je ż e l i n i e n a s t ą p i ł o ż ą d a n i e POST, # to tworzona j e s t p u s t a forma. e l s e : form = NameForm ( ) r e t u r n r e n d e r ( r e q u e s t, name. html, { form : form }) Szkielety tworzenia aplikacji 149

150 Dostęp do danych Po zakończonej sukcesem walidacji danych - metoda is_valid() zwraca True. Przesyłane dane są dostępne w postaci słownika form.cleaned_data (można też uzyskać do nieprzetworzonych danych bezpośrednio z wykorzystaniem request.post, gdzie request jest obiektem żądania). Dane są skonwertowane do odpowiednich typów Pythona. Szkielety tworzenia aplikacji 150

151 Logowanie użytkownika I Jeżeli istnieje potrzeba uwierzytelnienia użytkownika i dołączenia go do bieżącej sesji - należy użyć funkcji authenticate() i login(): from django. c o n t r i b. auth import a u t h e n t i c a t e, l o g i n d e f my_view ( r e q u e s t ) : username = r e q u e s t.post[ username ] password = r e q u e s t.post[ password ] u s e r = a u t h e n t i c a t e ( username=username, password= password ) i f u s e r i s not None : i f u s e r. i s _ a c t i v e : l o g i n ( r e q u e s t, u s e r ) # P r z e k i e r o w a n i e do s t r o n y zalogowanego u ż ytkownika. e l s e : # I n f o r m a c j a o tym, ż e u ż ytkownik n i e j e s t aktywny Szkielety tworzenia aplikacji 151

152 Logowanie użytkownika II... e l s e : # Obs ł uga niepoprawnego l o g o w a n i a... Szkielety tworzenia aplikacji 152

153 Wylogowanie użytkownika I Do wylogowania użytkownika służy funkcja logout(): from django. c o n t r i b. auth import l o g o u t d e f logout_view ( r e q u e s t ) : l o g o u t ( r e q u e s t ) # P r z e k i e r o w a n i e do s t r o n y wy ś w i e t l a n e j po wylogowaniu. Szkielety tworzenia aplikacji 153

154 Limitowanie dostępu do zawartości strony I Najprostszym sposobem ograniczenia dostępu do zawartości strony jest sprawdzenie za pomocą metody request.user.is_authenticated() czy użytkownik został zweryfikowany. W razie braku można przekierować użytkownika do strony logowania: from django. c o n f import s e t t i n g s from django. s h o r t c u t s import r e d i r e c t d e f my_view ( r e q u e s t ) : i f not r e q u e s t. u s e r. i s _ a u t h e n t i c a t e d ( ) : r e t u r n r e d i r e c t ( %s? n e x t=%s % ( s e t t i n g s. LOGIN_URL, r e q u e s t. path ) ) lub wyświetlić informację o błędzie: Szkielety tworzenia aplikacji 154

155 Limitowanie dostępu do zawartości strony II from django. s h o r t c u t s import r e n d e r d e f my_view ( r e q u e s t ) : i f not r e q u e s t. u s e r. i s _ a u t h e n t i c a t e d ( ) : r e t u r n r e n d e r ( r e q u e s t, myapp/ l o g i n _ e r r o r. html ) #... Oprócz tego Django daje dekorator login_required pozwalający na skrócenie zapisu: from django. c o n t r i b. auth. d e c o r a t o r s import l o g i n _ r e q u i r e l o g i n _ r e q u i r e d d e f my_view ( r e q u e s t ) :... Szkielety tworzenia aplikacji 155

156 Architektura aplikacji Qt Podstawowa architektura Qt: Niejawne współdzielenie obiektów Model obiektu Drzewa obiektów i własności obiektów Sygnały i sloty System zdarzeń System metaobiektów Szkielety tworzenia aplikacji 156

157 Niejawne współdzielenie obiektów I Wiele klas Qt korzysta z współdzielenia zasobów w celu minimalizacji operacji kopiowania. Zapisana w ten sposób klasa zawiera wkaźnik do współdzielonych danych i licznik odniesień. Podczas tworzenia obiektu licznik odniesień jest ustawiany na 1, zwiększa się wraz z tworzeniem nowych obiektów korzystających z współdzielonych danych natomiast zminiejsza się gdy obiekt nie korzysta już z współdzielonych danych. Współdzielone zasoby są niszczone gdy licznik odniesień zmniejszy się do zera. Szkielety tworzenia aplikacji 157

158 Niejawne współdzielenie obiektów II Strategia ta jest efektywna przy przekazywaniu obiektów klas jako argumentów wywołania funkcji, gdyż przekazywane są jedynie wskażniki do danych (płytkie kopiowanie), kopiowanie całości danych następuje jedynie wtedy, gdy funkcja zapisuje wartości do danych (głębokie kopiowanie) - aby nastąpiło automatycznie odłączenie obiektu od udostępnionych zasobów licznik odniesień musi być większy niż jeden.. Podejście umożliwia również efektywniejsze korzystanie z zasobów komputera, gdyż nie są niepotrzebnie kopiowane i duplikowane zasoby. Współdzielenie danych jest wykonywane niejawnie i nie musi być obsługiwane przez programistę. Szkielety tworzenia aplikacji 158

159 Model obiektu I Qt dodaje do klas C++ następujące elementy: mechanizm bezproblemowej komunikacji pomiędzy obiektami za pomocą sygnałów i slotów, mechanizm zdarzeń i filtrów zdarzeń, możliwe do przeszukiwania i zaprojektowania właściwości obiektów (property), zależną od kontekstu translacje łańcuchów znaków użyteczną do przygotowania różnych wersji językowych, Szkielety tworzenia aplikacji 159

160 Model obiektu II opartą na interwałach implementacje liczniki czasu (timer) umożliwiające wykonywanie wielu zadań w opartym na zdarzeniach graficznym interfejsie użytkownika, hierarchiczne i możliwe do przeszukiwania drzewo obiektów uwzględniające właścicieli obiektów, wskaźniki (QPointer) automatycznie ustawiane na 0, gdy obiekt na który wskazują zostaje zniszczony - pozwala to na uniknięcie wiszących wskaźników, dynamiczne rzutowanie działające poza granicami bibliotek. Szkielety tworzenia aplikacji 160

161 Model obiektu III Podstawowe klasy w modelu obiektu Qt QMetaClassInfo - zawiera dodatkowe informacje o klasie. QMetaEnum - zawiera metadane o typach wyliczeniowych. QMetaMethod - zawiera metadane o funkcji składowej. QMetaObject - zawiera metainformacje o obiektach Qt. QMetaProperty - zawiera metadane o właściwościach. QMetaType - zarządza typami w systemie metaobiektowym. Szkielety tworzenia aplikacji 161

162 Model obiektu IV QObject - klasa bazowa dla wszystkich obiektów Qt. QObjectCleanupHandler - pozwala na obserwowanie cyklu życiowego obiektów Qt. QPointer - klasa szablonowa, która zapewnia bezpieczne wskaźniki do obiektów Qt. QSignalMapper - pakuje sygnały z zidentyfikowanymi nadawcami. QVariant - działa jako unia dla najbardziej popularnych typów danych Qt. Szkielety tworzenia aplikacji 162

163 Model obiektu V void methodinformation(qobject* e) { const QMetaObject *mo = e->metaobject(); for(int i = mo->methodoffset(); i < mo->methodcount();++i) { QMetaMethod mmeth = mo->method(i); std::cout << mmeth.methodtype() << " " << mmeth.signature() << std::endl; } } Szkielety tworzenia aplikacji 163

164 System metaobiektów I System metaobiektowy jest oparty o: klasę QObject będącą klasą bazową dla obiektów, które mogą korzystać z systemu metaobiektów, makro Q_OBJECT umieszczone wewnątrz deklaracji klasy, które służy do włączenia cech metaobiektowych takich jak właściwości, sygnały czy sloty, narzędzie Meta-Object Compiler (moc), które wspomaga każdą podklasę QObject kodem niezbędnym do implementacji cech metaobiektów. Szkielety tworzenia aplikacji 164

165 System metaobiektów II Oprócz wspomagania komunikacji z wykorzystaniem sygnałów i slotów metaobiekty wprowadzają dodatkowe właściwości takie jak - QObject::metaObject(), QMetaObject::className(), QObject::inherits(), QObject::tr() i QObject::trUtf8(), QObject::setProperty() i QObject::property(), QMetaObject::newInstance(). Możliwe jest także wykonywanie dynamicznego rzutowania przy użyciu qobject_cast() klas z hierachii QObject. Funkcja qobject_cast() działa podobnie jak dynamic_cast() z standardowego C++ (dla wskaźników), nie wymaga jednak wsparcia dla RTTI i działa dla kodu z bibliotek dynamicznych. Szkielety tworzenia aplikacji 165

166 Drzewo obiektów I Obiekty Qt są organizowane w hierachiczne drzewo obiektów - podczas tworzenia obiektu klasy QObject z wykorzystaniem rodzica (parent), jest on włączany do listy dzieci (children()) tego rodzica, gdy rodzic jest niszczony to również niszczone są wszystkie jego dzieci. QWidget dodatkowo roszerza relację rodzic-dziecko. Dziecko jest wyświetlane w układzie współrzędnych rodzica i jest dopasowywane do granic rodzica. W sytuacji gdy obiekt jest niszczony w sposób niezależny, to wówczas usuwa on odniesienie do siebie z rodzica. Szkielety tworzenia aplikacji 166

167 Drzewo obiektów II Z reguły obiekty typu QObject powinny być tworzone na stercie (operator new), gdyż umożliwia to niszczenie obiektów drzewa w dowolnym porządku. Kiedy QObject w drzewie zostanie usunięty, jeśli ma rodzica, destruktor automatycznie usuwa odniesienie do tego obiektu z obiektu jego rodzica. Jeśli obiekt ma dzieci, destruktor automatycznie usuwa każde dziecko. Obiekty tworzone na stosie wymagają większej uwagi, gdyż konieczne jest sprawdzenie kolejności tworzenia obiektów. int main(int argc, char** argv) { QWidget window; QPushButton quit("quit", &window);... } Szkielety tworzenia aplikacji 167

168 Drzewo obiektów III int main() { QPushButton quit("quit"); QWidget window; } quit.setparent(&window);... Pierwszy przykład w porządku - obiekt quit usunie siebie z listy dzieci window natomiast w drugim problemem jest to, że nastąpi próba zniszczenia obiektu automatycznego z obiektu window. Szkielety tworzenia aplikacji 168

169 System zdarzeń I Zdarzenia są obiektami wyprowadzonymi z abstrakcyjnej klasy QEvent i reprezentują rzeczy, które mogą się zdarzyć w aplikacji lub jako wynik jakiejś zewnętrznej operacji, która powinna być znana przez program. Zdarzenia mogą być wysyłane i obsługiwane przez dowolną instancję podklasy QObject, ale najbardziej użyteczne są dla widgetów. Gdy zdarzenie się pojawia Qt tworzy obiekt odpowiedniego zdarzenia i dostarcza go do właściwej instancji QObject poprzez wywołanie funkcji event(). Funkcja ta nie przetwarza zdarzenia, lecz przekazuje go do odpowiedniej funkcji jego obsługi. Szkielety tworzenia aplikacji 169

170 System zdarzeń II Normalny sposób obsługi zdarzenia uwzględnia wywołanie odpowiedniej funkcji wirtualnej. Jeśli nie jest wykonywana w funkcji obsługi zdarzenia cała praca można przekazać sterowanie do funkcji z klasy nadrzędnej. void MyCheckBox::mousePressEvent(QMouseEvent *event) { if (event->button() == Qt::LeftButton) { //... } else { // Przekazanie do funkcji z klasy bazowej. QCheckBox::mousePressEvent(event); } } Szkielety tworzenia aplikacji 170

171 System zdarzeń III Zdarza się, że nie taka funkcja zdarzenia nie jest dostępna lub nie jest ona wystarczająca. Najbardziej typowy przykład to obsługa klawisza tabulacji. Normalnie, naciśnięcie klawisza Tab powoduje przeniesienie ogniska wejściowego klawiatury do następnego widgetu, niektóre widgety mogą jednak wymagać klawisza Tab dla własnych celów. Obiekty te mogą reimplementować funkcję QObject::event() - ogólny uchwyt dla zdarzeń. Szkielety tworzenia aplikacji 171

172 System zdarzeń IV bool MyWidget::event(QEvent *event) { if (event->type() == QEvent::KeyPress) { QKeyEvent *ke = static_cast<qkeyevent *>(event); if (ke->key() == Qt::Key_Tab) { // Specjalny sposób traktowania tabulacji return true; } } else if (event->type() == MyEvent) { MyEvent *me = static_cast<myevent *>(event); // obsługa własnego zdarzenie return true; } return QWidget::event(event); } Szkielety tworzenia aplikacji 172

173 System zdarzeń V Czasami obiekt musi możliwość zajrzenia i być może przechwycenia, zdarzeń, które są skierowane do innego obiektu. Funkcja QObject::installEventFilter() umożliwia ustanowienie filtru zdarzeń, który powoduje przekazanie zdarzenia do jego funkcji QObject::eventFilter(). Filtr zdarzeń otrzymuje do przetworzenia zdarzenie jeszcze przed obiektem docelowym, co pozwala na sprawdzenie i ewentualne, jeśli istnieje taka potrzeba, odrzucenie zdarzenia. Istniejący filtr zdarzeń można usunąć za pomocą funkcji QObject::removeEventFilter(). Podczas wywołania funkcji eventfilter() można zaakceptować lub odrzucić zdarzenie oraz zezwolić lub odmówić dalszego przetwarzania zdarzenia. Jeśli wszystkie filtry zdarzeń umożliwiają dalsze przetwarzania zdarzenia (poprzez zwracanie false), to zdarzenie jest wysyłane do obiektu docelowego. Jeśli jeden z nich zatrzymuje przetwarzanie (zwracając true) cel i inne filtry nie są w ogóle w stanie zobaczyć to zdarzenie. Szkielety tworzenia aplikacji 173

174 System zdarzeń VI bool FilterObj::eventFilter(QObject *o, QEvent *e) { if (o == target && e->type() == QEvent::KeyPress) { QKeyEvent *kev = static_cast<qkeyevent *>(e); if (kev->key() == Qt::Key_Tab) { // Specjalny sposób przetwarzania Tab return true; } else return false; } return false; } Szkielety tworzenia aplikacji 174

175 System zdarzeń VII Możliwe jest również filtrowanie wszystkich zdarzeń dla całej aplikacji poprzez zainstalowanie filtra zdarzeń na obiekcie QApplication lub QCoreApplication. Te globalne filtry zdarzeń są wywoływane przed filtrami poszczególnych obiektów. Wiele aplikacji może tworzyć i wysyłać własne zdarzenia. Można wysłać zdarzenia w dokładnie w ten sam sposób jak w pętli komunikatów Qt poprzez tworzenie odpowiednich obiektów zdarzeń i wysyłania ich za pomocą QCoreApplication::sendEvent() i QCoreApplication::postEvent(). Funkcja sendevent() przetwarza zdarzenie natychmiast. Kiedy kończy działanie, filtr zdarzenia lub sam obiekt docelowy przetwarza od razu zdarzenie. Szkielety tworzenia aplikacji 175

176 System zdarzeń VIII Funkcja postevent() wstawia zdarzenie w kolejce do późniejszego przesłania. Następnym razem, gdy jest wywoływana główna pętla zdarzeń Qt wysyła wszystkie zdarzenia z kolejki z wykonaniem pewnych optymalizacji. Na przykład, jeśli istnieje kilka zdarzeń zmiany rozmiaru, są one łączone w jedno wywołanie. To samo dotyczy się odmalowywania obiektu. Utworzenie zdarzenia o niestandardowym typie wymaga określenia numeru zdarzenia, który musi być większy niż QEvent::User, a może także wymagać utworzenia podklasy QEvent w celu przekazania szczegółowych informacji na temat tego niestandardowego zdarzenia. Szkielety tworzenia aplikacji 176

177 Zarządzanie wielkością kontrolki I Klasa QSizePolicy: Jest atrybutem managera układu, opisuje pionowe i poziome zarządzanie rozmiarami kontrolki. Wyraża wymagania widgetu odnośnie zmiany jego rozmiaru i opisuje jak widget ma być traktowany przez manager układu. Zawiera dwie niezależne wartości QSizePolicy i dwa współczynniki rozsciągania opisujące zarządzanie wielkością widgetu w pionie i w poziomie. Ponadto zawiera również flagę PolicyFlag wskazującą czy wysokość i szerokość widgetu są powiązane z jego preferowaną wielkością. Szkielety tworzenia aplikacji 177

178 Zarządzanie wielkością kontrolki II Flagi QSizePolicy::PolicyFlag: QSizePolicy::GrowFlag - widget może powiększać swój rozmiar poza rozmiar zalecany jeśli jest to konieczne. QSizePolicy::ExpandFlag - widget zajmuje największą możliwą przestrzeń. QSizePolicy::ShrinkFlag - widget może zmniejszać swój rozmiar poniżej rozmiaru zalecanego jeśli jest to konieczne. QSizePolicy::IgnoreFlag - rozmiar zalecany jest ignorowany, widget zajmuje największą możliwą przestrzeń. Szkielety tworzenia aplikacji 178

179 Zarządzanie wielkością kontrolki III Rodzaje zarządzania wielkością: QSizePolicy::Fixed(0) - rozmiar zalecany jest jedynym możliwym QSizePolicy::Minimum (GrowFlag) QSizePolicy::Maximum (ShrinkFlag) QSizePolicy::Preferred (GrowFlag ShrinkFlag) QSizePolicy::Expanding (GrowFlag ShrinkFlag ExpandFlag) QSizePolicy::MinimumExpanding (GrowFlag ExpandFlag) QSizePolicy::Ignored (ShrinkFlag GrowFlag IgnoreFlag) Szkielety tworzenia aplikacji 179

180 Zarządzanie wielkością kontrolki I Klasa QSizePolicy: Jest atrybutem managera układu, opisuje pionowe i poziome zarządzanie rozmiarami kontrolki. Wyraża wymagania widgetu odnośnie zmiany jego rozmiaru i opisuje jak widget ma być traktowany przez manager układu. Zawiera dwie niezależne wartości QSizePolicy i dwa współczynniki rozsciągania opisujące zarządzanie wielkością widgetu w pionie i w poziomie. Ponadto zawiera również flagę PolicyFlag wskazującą czy wysokość i szerokość widgetu są powiązane z jego preferowaną wielkością. Szkielety tworzenia aplikacji 180

181 Zarządzanie wielkością kontrolki II Flagi QSizePolicy::PolicyFlag: QSizePolicy::GrowFlag - widget może powiększać swój rozmiar poza rozmiar zalecany jeśli jest to konieczne. QSizePolicy::ExpandFlag - widget zajmuje największą możliwą przestrzeń. QSizePolicy::ShrinkFlag - widget może zmniejszać swój rozmiar poniżej rozmiaru zalecanego jeśli jest to konieczne. QSizePolicy::IgnoreFlag - rozmiar zalecany jest ignorowany, widget zajmuje największą możliwą przestrzeń. Szkielety tworzenia aplikacji 181

182 Zarządzanie wielkością kontrolki III Rodzaje zarządzania wielkością: QSizePolicy::Fixed(0) - rozmiar zalecany jest jedynym możliwym QSizePolicy::Minimum (GrowFlag) QSizePolicy::Maximum (ShrinkFlag) QSizePolicy::Preferred (GrowFlag ShrinkFlag) QSizePolicy::Expanding (GrowFlag ShrinkFlag ExpandFlag) QSizePolicy::MinimumExpanding (GrowFlag ExpandFlag) QSizePolicy::Ignored (ShrinkFlag GrowFlag IgnoreFlag) Szkielety tworzenia aplikacji 182

183 Podstawowe pojęcia Wielobieżność (ang. reentrant) - Klasa jest wielobieżna jeśli jest bezpieczne używanie jej instancji z więcej niż jednego wątku, pod warunkiem, że najwyżej jeden wątek ma dostęp do tej samej instancji klasy w tym samym czasie. Funkcja jest wielobieżna jeśli jest bezpieczne wywoływanie jej z więcej niż jednego wątku w tym samym czasie, pod warunkiem, że każde jej wywołanie odnosi się do unikalnych danych. Bezpieczeństwo ze względu na wątki (ang. thread safe) - Klasa jest bezpieczna ze względu na wątki jeśli możliwe jest bezpieczne korzystanie z jej instancji w więcej niż jednym wątku. Funkcja jest bezpieczna ze względu na wątki jeśli jest bezpieczne wywoływanie jej w więcej niż jednym wątku w tym samem czasie nawet jeśli wywołanie odnosi się do współdzielonych danych. Szkielety tworzenia aplikacji 183

184 Przykłady wielobieżności i bezpieczeństwa I class Licznik { public: Licznik():n(0) {} void increment() { ++n; } void decrement() { --n; } int value() const { return n; } private: int n; }; Szkielety tworzenia aplikacji 184

185 Przykłady wielobieżności i bezpieczeństwa II class Licznik { public: Licznik():n(0) {} void increment() {QMutexLocker lock(&mut); ++n;} void decrement() {QMutexLocker lock(&mut); --n; } int value() const {QMutexLocker lock(&mut); return n;} private: mutable QMutex mut; int n; }; Szkielety tworzenia aplikacji 185

186 QThread I QThread Klasa dostarcza niskopoziomowego API wspierającego pracę na wątkach. Obiekt tej klasy (podklasy) reprezentuje pojedynczy wątek, współdzieli on dane z innymi wątkami uruchomionymi w tym samym procesie, ale jest uruchomiony oddzielnie. Ukrywa wszystkie zależne od konkretnego systemu operacyjnego szczegóły implementacyjne. Każdy wątek posiada własną pętlę komunikatów. Umożliwia to wymianę informacji pomiędzy wątkami z wykorzystaniem mechanizmu sygnałów i slotów. Szkielety tworzenia aplikacji 186

187 QThread II class MyThread : public QThread { protected: void run() { /* implementacja */ } }; MyThread *t = new MyThread; t->start(); Szkielety tworzenia aplikacji 187

188 QThread III class Worker : public QObject { Q_OBJECT public slots: void dowork() { /* Implementacja */ } }; QThread *thread = new QThread; Worker *worker = new Worker; //Wskaźnik obj jest wyzwalaczem powodującym start zadania connect(obj, SIGNAL(startWork()), worker, SLOT(doWork())); worker->movetothread(thread); thread->start(); Szkielety tworzenia aplikacji 188

189 QRunnable i QThreadPool I QRunnable jest lekką, abstrakcyjną klasą, która może być użyta do rozopoczynania zadań w innym wątku w postaci "uruchom i zapomnij". W celu osiągnięcia tych zadań dziedziczy się po klasie QRunnable i implementuje czysto abstrakcyjną metodę run(): class MyTask : public QRunnable { public: void run() { /* Implementacja */ } }; Szkielety tworzenia aplikacji 189

190 QRunnable i QThreadPool II W celu rzeczywistego uruchomienia obiektu QRunnable używa się klasy QThreadPool, która zarządza pulą wątków. Poprze wywołanie QThreadPool::start(runnable) umieszcza się obiekt QRunnable w kolejce uruchomionych wątków QThreadPool. Tak szybko jak tylko wątek staje się dostępny, obiekty QRunnable są zbierane i uruchomiene do takiego wątku. Każda aplikacja Qt posiada globalną pulę wątków dostępną poprzez wywołanie QThreadPool::globalInstance(), ale zawsze można utworzyć własną prywatną instancję QThreadPool i zarządzać nią jawnie. QRunnable nie jest podklasą QObject dlatego też nie ma wbudowanej komunikacji z innymi komponentami, dlatego wymagane jest ręczna obsługa takiego kodu przy użyciu niskopoziomowych mechanizmów wątków (jak strzeżona przez muteksy kolejka dla zbierania wyników). Szkielety tworzenia aplikacji 190

191 QConcurrent I QtConcurrent jest wysokopozimowym API zbudowanym na szczycie QThreadPool, przydatnym do wykonywania zadań z użyciem popularnych modeli obliczeń równoległych: mapowanie, redukcja i filtrowanie Oferuje także metodę QtConcurrent::run (), którą można wykorzystać do łatwego uruchomienia funkcji w innym wątku. W przeciwieństwie do QThread i QRunnable, QtConcurrent nie wymaga stosowania niskopoziomowych mechanizmów synchronizacji. Szkielety tworzenia aplikacji 191

192 Mechanizmy bezpiecznego synchronizowania wątków I QMutex i QMutexLocker - służą do zablokowania dostępu do pewnej sekcji kodu, sekcji krytycznej QReadWriteLock - umożliwia blokowanie obiektów do zapisu/odczytu QSemaphore - umożliwia tworzenie semaforów (uogólnienie muteksów) QWaitCondition - wprowadza zmienne, które umożliwiają synchronizację wątków Szkielety tworzenia aplikacji 192

193 Sygnały i sloty pomiędzy wątkami I Qt oferuje mechanizm wysyłania zdarzenia w kolejce komunikatów wątku, natomiast obsługa zdarzenia jest wykonywana w odpowiedniej przeznaczonej do tego celu metodzie. Mechanizm ten jest zbudowany za pomocą introspekcji metod realizowanej przez moc, dlatego tylko sygnały, sloty i metody oznaczone makrem Q_INVOKABLE mogą być wywoływane z innych wątków. Szkielety tworzenia aplikacji 193

194 Sygnały i sloty pomiędzy wątkami II Typy połączeń: bezpośrednie - oznacza, że slot jest zawsze wywoływany bezpośrednio przez wątek emitowanego sygnału, kolejkowane - oznacza, że zdarzenie jest zapisane w kolejce zdarzeń wątku odbiorcy, które będą zabierane przez pętlę komunikatów i wysyłane do gniazd jakiś czas później, kolejkowane blokowane - połączenie jest realizowane jak w połączeniu kolejkowanym, ale blokuje wątek nadawcy, aż do chwili, gdy slot zakończy działanie, powinno być używane jedynie wtedy, gdy nadawca i odbiorca są w innych wątkach, automatyczne (domyślnie) - oznacza, że jeśli wątek odbiorcy w tym samym bieżącym wątku to używane jest bezpośrednie połączenie, w przeciwnym przypadku używane jest kolejkowane połączenie. Szkielety tworzenia aplikacji 194

195 System pluginów Qt dostarcza dwóch API do tworzenia pluginów: Wysokopoziomowego API do tworzenia pluginów dla biblioteki Qt np.: sterowników bazy danych (QSqlDriverPlugin), kodeków tekstowych (QTextCodecPlugin), obsługi dodatkowych formatów obrazu (QImageIOPlugin), własnych stylów (QStylePlugin). Implementacja polega na zapewnieniu klasy dziedziczącej po jednej z klas, dostarczeniu odpowiednich metod i dodaniu makra. Są przechowywane w standardowych katalogach Qt Niskopoziomowego API przeznaczonego do rozszerzenia aplikacji korzystających z biblioteki Qt. Szkielety tworzenia aplikacji 195

196 Niskopoziomowe API I Utworzenia aplikacji, która będzie mogła być rozszerzana za pomocą pluginów wymaga następujących czynności: 1 Zdefiniowanie zbioru interfejsów (klas z jedynie czysto wirtualnymi funkcjami - poza destruktorem) używanych do późniejszej implementacji pluginów. 2 Użycia w kodzie makra Q_DECLARE_INTERFACE() w celu poinformowania systemu metaobiektowego Qt o interfejsie. 3 Użycia obiektu klasy QPluginLoader do załadowania pluginu. 4 Przetestowania za pomocą qobject_cast() czy dany plugin implementuje określony interfejs. Szkielety tworzenia aplikacji 196

197 Niskopoziomowe API II Tworzenie pluginu wymaga wykonania następujących kroków: 1 Zdefiniowanie klasy pluginu dziedziczącej po QObject i z klasy zdefiniowanej wcześniej klasy interfejsu jaki ma zapewniać. 2 Użycie w kodzie makra Q_INTERFACES() w celu poinformowania systemu metaobiektów biblioteki Qt o implementowanym interfejsie. 3 Wyeksportowanie pluginu przy pomocy makra Q_EXPORT_PLUGIN2(). 4 Budowa pluginu przy pomocą odpowiedniego pliku.pro. Szkielety tworzenia aplikacji 197

198 Definicja interfejsu dla pluginów #ifndef SYNTAXHIGHLIGHTERPLUGIN_H #define SYNTAXHIGHLIGHTERPLUGIN_H class QStringList; class QSyntaxHighlighter; class SyntaxHighlighterPluginInterface { public: virtual ~SyntaxHighlighterPluginInterface(){} virtual QSyntaxHighlighter* getsyntaxhighlighter() = 0; virtual QStringList getfileextensions() = 0; }; Q_DECLARE_INTERFACE(SyntaxHighlighterPluginInterface, "com.sztap.syntaxhighlighterplugininterface/1.0") #endif // SYNTAXHIGHLIGHTERPLUGIN_H Szkielety tworzenia aplikacji 198

199 Implementacja interfejsu dla pluginów #ifndef STYLEPLUGIN_H #define STYLEPLUGIN_H #include <QObject> #include <syntaxhighlighterplugin.h> class StylePlugin : public QObject, public SyntaxHighlighterPluginInterface { Q_OBJECT Q_INTERFACES(SyntaxHighlighterPluginInterface) public: QSyntaxHighlighter* getsyntaxhighlighter(); QStringList getfileextensions(); }; #endif // STYLEPLUGIN_H Szkielety tworzenia aplikacji 199

200 Ładowanie pluginów void MainWindow::loadPlugins() { QDir pluginsdir = directoryof("plugins"); foreach(qstring filename, pluginsdir.entrylist(qdir::files)) { QPluginLoader loader(pluginsdir.absolutefilepath(filename)); if(syntaxhighlighterplugininterface *interface = qobject_cast<syntaxhighlighterplugininterface*>(loader.instance())) { foreach(qstring fileext, interface->getfileextensions()) fileextmap[fileext] = interface; } } } Szkielety tworzenia aplikacji 200

201 Modele-Widoki w Qt Szkielety tworzenia aplikacji 201