Budowanie zaawansowanych aplikacji webowych za pomocą framework a Django

Transkrypt

1 Kierunek studiów: Informatyka Specjalność: Technologie informacyjne i internetowe Nr albumu: Dominik Nowakowski Budowanie zaawansowanych aplikacji webowych za pomocą framework a Django Building advanced web applications using framework "Django" Praca inżynierska napisana pod kierunkiem dr Krzysztofa Krzywdzińskiego Poznań 2017

2 Poznań, dnia... OŚWIADCZENIE Ja, niżej podpisany/a Dominik Nowakowski student Wydziału Matematyki i Informatyki Uniwersytetu im. Adama Mickiewicza w Poznaniu oświadczam, że przedkładaną pracę dyplomową pt: Budowanie zaawansowanych aplikacji webowych za pomocą framework a Django napisałem samodzielnie. Oznacza to, że przy pisaniu pracy, poza niezbędnymi konsultacjami, nie korzystałem z pomocy innych osób, a w szczególności nie zlecałem/am opracowania rozprawy lub jej części innym osobom, ani nie odpisywałem tej rozprawy lub jej części od innych osób. Oświadczam również, że egzemplarz pracy dyplomowej w wersji drukowanej jest całkowicie zgodny z egzemplarzem pracy dyplomowej w wersji elektronicznej. Jednocześnie przyjmuję do wiadomości, że przypisanie sobie, w pracy dyplomowej, autorstwa istotnego fragmentu lub innych elementów cudzego utworu lub ustalenia naukowego stanowi podstawę stwierdzenia nieważności postępowania w sprawie nadania tytułu zawodowego. [ ]* - wyrażam zgodę na udostępnianie mojej pracy w czytelni Archiwum UAM [ ]* - wyrażam zgodę na udostępnianie mojej pracy w zakresie koniecznym do ochrony mojego prawa do autorstwa lub praw osób trzecich *Należy wpisać TAK w przypadku wyrażenia zgody na udostępnianie pracy w czytelni Archiwum UAM, NIE w przypadku braku zgody. Niewypełnienie pola oznacza brak zgody na udostępnianie pracy.... 1

3 Spis Treści Wstęp...4 Abstract Framework Django Wstęp Charakterystyka framework a Django Podstawowa struktura projektu Django Folder główny Django Foldery aplikacji Static i Media Manage.py Architektura projektu Tworzenie nowego projektu Tworzenie wirtualnego środowiska Wymagania Utworzenie nowego projektu Tworzenie nowej aplikacji Baza danych i modele Łączenie z bazą danych Migracje Modele Struktura bazy danych ORM w Django URL Działanie URL w Django Definiowanie adresów URL Przekierowywanie adresów URL do aplikacji Widoki Definiowanie widoków Dekoratory Widoki na bazie klas..24 2

4 5 Formularze Standardowe formularze HTML, a Django Formularze Django Tworzenie formularza Django Użycie formularza w widoku Użycie formularza w szablonie Formularze na bazie Modeli Szablony Zmienne Tagi Panel Administracyjny Django Rest Framework Serializacja Widoki na bazie serializatora Tworzenie URL dla REST API Interfejs Integracje USOS Facebook SMTP..44 Podsumowanie...46 Bibliografia

5 Wstęp Strony internetowe już dawno przestały pełnić rolę encyklopedii gdzie możemy tylko odczytać zdefiniowaną w nich przez autora treść. Obecnie takie podejście do robienia stron dopuszczalne jest wyłącznie do bardzo małych i prostych stron mających na celu na przykład przedstawienie firmy - choć nawet i tutaj zalecane jest zupełnie inne podejście. Dzisiejsze strony internetowe stawiają na interakcje z użytkownikami. Zamiast wyświetlania tych samych danych dla każdego użytkownika, aplikacje internetowe dla niego przetwarzają i generują dane zależnie od podjętych czynności. Im prostsza jest interakcja dla użytkownika (powinno dążyć się do zautomatyzowania jak największej liczby czynności), generująca przy tym jak najbardziej pożądane przez niego dane - tym lepiej. Niniejsza praca przedstawia proces tworzenia zaawansowanych aplikacji webowych w języku programowania python z wykorzystanie frameworka Django na przykładzie portalu ElStudent. Główne założenia portalu ElStudent: Dostęp do portalu wymaga aktywnego konta użytkownika. Aktywne konto uzyskuje się po rejestracji przez formularz, lub portal Facebook, a następnie integracji z systemem USOS, Na podstawie integracji z systemem USOS użytkownik, czyli aktywny student przypisywany jest do odpowiednich grup zajęciowych i kierunków studiów, Użytkownik na stronach zajęć i kierunków prowadzić może dyskusję z innymi uczestnikami publikując posty, lub notatki, Użytkownik może wyszukiwać i dodawać/usuwać/zapraszać innych użytkowników do swoich znajomych, Użytkownik może uzupełnić swój profil danymi takimi jak umiejętności czy doświadczenia, oraz oglądać profile innych użytkowników, Użytkownik dostaje powiadomienia o aktywności innych powiązanych z nim użytkowników, Użytkownik ma możliwość kontaktu z administratorami, Użytkownik może mieć nadane prawa moderatora i dostęp do panelu zarządzania, Użytkownik ma dostęp do komunikatora utworzonymi pokojami na podstawie jego danych, Interfejs jest lekki i przejrzysty, strona jest responsywna i zrobiona pod kątem łatwego SEO, Strona jest dynamiczna tzn. za pomocą integracji REST API z AngularJS nowe dane wyświetlane są użytkownikowi bez konieczności przeładowywania strony, Strona jest zabezpieczona przed atakami różnego typu, a także przed wyciekiem danych. 4

6 Abstract Websites are no longer play the role of an encyclopedia where you can only read defined by the author content. Currently, such an approach to make websites is acceptable only for a very small and simple sites aimed for example, presentation of the company - though even here it is recommended a completely different approach. Today's websites rely on interactions with users. Instead of displaying the same data for each user, web-based applications in response generate data depending on the action taken. The simpler the interaction to the user (should automate as many steps as possible), generating at the same time as most desired data - the better. This thesis presents the process of creating advanced Web applications in the programming language Python with using Django framework based of the portal ElStudent. The main assumptions of the portal ElStudent: Access to the portal requires an active user account. Active account obtained after the registration form, or portal Facebook, and integration with USOS after it, Based on integration with USOS user, which is an active student is assigned to the relevant courses and programmes, User on courses and programme pages can lead discussions with other participants by publishing posts, or notes, The user can search and add / delete / invite other users to their friends, The user can fill up your own profile data such as skills and experience, and view profiles of other users, The user gets a notification about the activity of other associated users, The user has the possibility of contact with the administrators, User may have given moderator privileges and access to the management interface, User have access to chat module with created rooms based on its data, The interface is light and transparent, the site is responsive and made for easy SEO, The website is dynamic, ie. it using the REST API for integration with angularjs - new data are displayed for a user without reloading the page, This page is protected against attacks of various types, as well as against data leakage. 5

7 1. Framework Django 1.1 Wstęp Django jest to darmowy framework przeznaczony do tworzenia aplikacji internetowych. Swoje początki ma pod koniec 2013 roku. Głównym celem Django jest uproszczenie pisania aplikacji internetowych zasilanych przez bazy danych. Framework sam w sobie zasilony jest najważniejszymi podstawowymi funkcjonalnościami, które powtarzają się na niemalże większości stron. Twórcy jednak skupili się na bardzo łatwym instalowaniu dodatkowych aplikacji tworzonych przez innych użytkowników co czyni potencjał Django niemalże nieograniczonym. Świadczy o tym chociażby używanie w całości lub części tego framework a przez portale jak: instagram, disqus, spotify, nasa, bitbucket, prezi 1.2 Cechy Django: Django nie jest standardowym framework iem MVC (Model-View-Controller). Choć można go tak nazwać, twórcy wolą określenie MTV (Model-Template-View). Wynika to z tego, że w MVC widok odpowiada za nie za to jak dane są prezentowane, a jedynie kiedy. W przypadku Django widok to funkcja w języku Python, która jest odpowiedzią na wywołanie danego URL i definiuje jakie dane są prezentowane. Widok także odwołuje się do szablonu, który dopiero pokazuje jak dane są przedstawiane użytkownikom. Odpowiednikiem kontrolera natomiast jest framework sam w sobie, a dokładniej mechanizm wysyłający zapytania do widoku na podstawie URL. Darmowy na otwartej licencji BSD, Współpraca z Apache za pomocą WSGI, oraz innymi serwerami przy użyciu protokołów FastCGI, oraz SCGI, Posiada wsparcie dla budowania aplikacji wielojęzykowych, Wzoruje się bardzo dużą wydajnością w stosunku do obciążanie, Wspiera wiele metod cache owania, Posiada wbudowany serwer służący do rozwijania aplikacji i jej testowania, Bardzo prosty i wydajny system szablonów zarówno dla programistów back-end jak i front-end, 6

8 Używa zasady DRY w budowaniu aplikacji internetowych, mówiącej o jak najczęstszym unikaniu powtarzania funkcjonalności (np. używa wiele klas,metod i funkcji z języka python), ORM pozwala użytkownikom na stworzenie wydajnych i bezpiecznych baz danych bez dużej znajomości SQL, Współpracuje z wieloma rodzajami baz danych takimi jak MySQL, PostgreSQL, SQLite, Oracle czy MSSQL, Wraz z projektem tworzony jest kompletny panel administracyjny z możliwością dostosowania go do własnych potrzeb, 1.3 Podstawowa Struktura Django W tym rozdziale omówiona została struktura Django na przykładzie projektu ElStudent. Trzymanie się struktury projektu wytyczonej przez standardy ma wiele korzyści, wśród nich wymienić można uporządkowane pliki i foldery dzięki czemu łatwo odnaleźć szukany cel czy też zgodność z innymi członkami zespołu. 7

9 1.3.1 Folder główny Django Jest to najważniejszy folder naszego projektu, zawiera wszystkie niezbędne dane wspólne dla całego projektu. Podstawowe pliki folderu głównego to: init.py - Jest to pusty plik mówiący Python owi o tym, że folder jest pakietem Python a, settings.py - Kluczowy plik projektu, zawierający wszystkie jego ustawienia i dane konfiguracyjne. Zdefiniować tam możemy na przykład: nasze połączenie z bazą danych, sposób zarządzania sesjami, szablonami, nasze aplikacje, urls.py - W tym pliku możemy przypisać widoki zależnie od wywołanego URL, dobrym sposobem użytym w tym projekcie jest przekierowanie stąd ruchu do pliku urls.py w aplikacjach gdzie dopiero można przypisać URL do danego widoku, wsgi.py - Plik służący do integracji naszego projektu z WSGI (ma to zastosowanie w ustawianiu naszego projektu na serwerze) Foldery aplikacji Są to pakiety Python a służące określonemu przez nas celowi. Są zależne od folderu głównego, który jest wspólnym mostem łączącym wszystkie aplikacje. 8

10 Podstawowe pliki folderu aplikacji: init.py - Dokładnie tak samo jak w folderze głównym jest to pusty plik mówiący Python owi o tym, że folder jest pakietem Python a, admin.py - Plik służący do konfiguracji aplikacji z panelem administracyjnym Django, forms.py - Plik zawierający formularze Django, models.py - Tutaj można zdefiniować nasze modele, urls.py - Jeżeli jest przekierowanie ruchu z urls.py folderu głównego tutaj, jest to miejsce gdzie bezpośrednio możemy przypisać widoki do adresów URL, w przeciwnym wypadku ten plik jest zbędny gdyż będziemy zajmować się tym już w katalogu głównym views.py - Plik w którym można definiować widoki migrations - Katalog zawierający pliki opisujące wszystkie nasze migracje danych do bazy danych, static - Katalog z plikami statycznymi aplikacji, templates - Katalog z szablonami naszej aplikacji Static i Media Static - jest to katalog zawierający wszystkie pliki statyczne zbierane z katalogów static poszczególnych aplikacji. Media - katalog ten zawiera wszystkie pliki, które nie są stałą zawartością projektu. Przeważnie służy on do przechowywania plików przysłanych przez użytkowników projektu Manage.py Jest to niezwykle użyteczne narzędzie działające z linii poleceń. W zależności od danego polecenia pozwala na interakcje z naszym projektem na wiele sposobów. 1.4 Architektura Projektu Dobra architektura projektu pozwala na spójny i szybki przepływ danych co bezpośrednio przekłada się na wydajność i efektywność projektu. Ważne jest prawidłowe połączenie warstw logicznych, a także poza framework iem dobrze zaplanować użycie innych komponentów. 9

11 Na żądanie użytkownika (wejście na dany adres URL/wykonanie specyficznej akcji) framework Django generuje właściwą odpowiedź na podstawie architektury pokazanej powyżej. Wszystkie nasze dane znajdują się w bazie danych ( w projekcie ElStudent jest to baza danych MySQL). Aby umożliwić połączenie Django z bazą danych potrzebna jest aplikacja do języka python umożliwiająca nawiązanie tego połączenia - w tym projekcie wybór padł na aplikacje mysqlclient. 10

12 Dane z bazy danych przetwarzane są przez ORM -Object Related Mapper. Jest to biblioteka frameworka, która ma na celu zautomatyzowanie transferu danych zawartych w relacyjnych bazach danych do obiektów języka python. Dalej nasze dane przechodzą przez wspomniany już wcześniej model MVT. Model jest definicją naszego obiektu opisującego strukturę, oraz relacje w naszej bazie danych. Gdy nasze informacje z bazy danych są pobierane i przetwarzane w obiekty trafiają do odpowiedniego widoku. W widoku należy zdefiniować przetwarzanie tych danych, oraz naszą odpowiedź do użytkownika. Odpowiedzią tą może być, choć nie musi - odpowiedni szablon, do którego umieścić możemy dane generowane z widoku, czy też wczytać pliki statyczne i medialne. Odpowiedź ta wyzwalana jest przez URL, gdzie wraca do użytkownika wysyłającego żądanie. Powyżej opisana została podstawowa architektura frameworka Django. Możliwość łatwej integracji zarówno z dodatkowymi aplikacjami Django jak i tymi zewnętrznymi umożliwia nam niemal nieograniczone rozbudowywanie tejże architektury. Projekt ElStudent wzbogacony został dodatkowo w: Formularze Django, które łatwo integrują się z naszymi modelami, następnie trafiają do odpowiedniego widoku, który umieszcza je w szablonach gdzie przekształcane są w odpowiadające im formularze HTML, Django Rest Framework, służący do generowania aplikacji typu REST. W widoku pobieramy nasze dane z bazy danych na podstawie modelu następnie trafiają one do serializatora, który mówi jak te dane mają być reprezentowane w aplikacji typu REST. AngularJS, pobierający dane z naszych aplikacji REST i wyświetlający je na bieżąco w naszych szablonach, Django Channels, aplikacja służąca podobnie jak wyżej wymieniony AngularJS do dynamicznego przesyłania danych w szablonie użyta w projekcie ElStudent do komunikatora 1.5 Tworzenie Projektu Django Ideą framework a Django jest możliwość szybszego tworzenia tak samo zaawansowanych aplikacji internetowych niż najbardziej popularne konkurencyjne frameworki. Kierując się właśnie tym, większość mechanizmu powstawania nowego projektu jest zautomatyzowana. Dzięki temu od użytkownika wymagana jest bardzo mała ilość pracy, a projekt powstaje bardzo szybko. 11

13 1.5.1 Tworzenie wirtualnego środowiska Wirtualne środowisko jest nam potrzebne do wyodrębnienia specjalnego środowiska python a wyłącznie dla naszego projektu. Dzielenie jednego środowiska pythona dla wielu projektów może powodować wiele konfliktów - począwszy od samej wersji python a. Nie wspominając już o umieszczaniu projektu na hostingu dzielonym gdzie nie mamy dostępu do modyfikowania głównego środowiska. Wirtualne środowisko możemy stworzyć komendą: virtualenv - p python3 venv Następnie w celu użycia należy aktywować komendą: source / scieżka / do /venv/ bin / activate Wymagania Żeby przejść do tworzenia projektu Django musimy spełnić określone wymagania. Poza odpowiednią wersją pythona potrzebne są dla projektu ElStudent: Do ich instalowania zalecany jest wbudowany w najnowsze wersje pythona zarówno 2 i 3 - pip. W celu łatwiejszego deponowania projektu u innych developerów jak i na serwerze dobrą metodą jest zapisywanie listy wymagań w pliku requirements. Tym samym możemy bardzo szybko zainstalować wszystkie niezbędne aplikacje jedną komendą: pip install - r requirements. txt 12

14 1.5.3 Utworzenie nowego projektu Nowy projekt tworzymy komendą: django - admin startproject Nazwa_Projektu W tym momencie framework stworzy nam nowy projekt z podaną przez nas nazwą. Zawarte w nim będą folder główny projektu z domyślnymi plikami i ustawieniami, manage, oraz panel administracyjny. Projekt możemy uruchomić lokalnie dzięki wbudowanemu serwerowi developerskiemu Django: python manage. py runserver 1.6 Tworzenie nowej aplikacji Nową aplikację stworzyć możemy komendą: python manage. py startapp nazwa_aplikacji Podobnie jak przy tworzeniu projektu utworzy nam się folder aplikacji z podstawową strukturą i domyślnymi danymi. Aby projekt wiedział, że ma traktować ten folder jako swoją aplikację do INSTALLED_APPS w pliku settings.py należy dodać jej nazwę. 13

15 2. Baza danych i modele Odpowiednia struktura i relacje bazy danych projektu są najważniejszym etapem projektowania aplikacji internetowej. O ile często można zmienić lub poprawić dany komponent nawet po wdrożeniu projektu, na wypełnionej danymi bazie danych każda zmiana może okazać się niemożliwą bądź bardzo trudną operacją. Django posiada narzędzia pozwalające tworzyć rozbudowane bazy danych i przeprowadzać na nich zaawansowane operacje bez znajomości specyficznych dla nich języków jak SQL. 2.1 Łączenie z bazą danych Przed połączeniem z bazą danych musimy upewnić się, że mamy zainstalowaną odpowiednią aplikację do python a umożliwiającą to połączenie. Następnie możemy przystąpić do połączenia do bazy danych, co odbywa się przez zdefiniowanie odpowiednich ustawień w pliku settings.py Definicje naszego połączenia należy zacząć od podania nazwy reprezentatywnej naszej bazy danych dla projektu Django, następnie w klamrach podajemy niezbędne dane i opcje połączenia. Oczywiście dla względów bezpieczeństwa projektu dane te zostały ukryte. 2.2 Migracje Po zdefiniowaniu naszego połączenia Django do prawidłowego działania potrzebuje umieścić w niej swoje tabele. Uruchamiając polecenie python manage. py migrate - framework wprowadzi odpowiednie zmiany w bazie danych. Przy pierwszym uruchomieniu Django wykryje brak podstawowych tabel. Aby wiedział jakie zmiany należy wnieść na podstawie naszych modeli i aplikacji trzeba porównać strukturę naszego projektu ze 14

16 strukturą bazy danych. Można to zrobić poleceniem python manage. py makemigrations, które wygeneruje wszystkie niezbędne informacji do migracji w folderach migrations odpowiednich aplikacji. Z tych plików polecenie python manage. py migrate odczyta niezbędne instrukcje. 2.3 Modele Modele należy zdefiniować w pliku o nazwie models.py w folderach aplikacji. Każdy model jest klasą języka python, która jest subklasą django. db. models. Model Każdy atrybut definiuje kolumnę w bazie danych Każdy model definiuje tabelę w bazie danych Powyższy przykład demonstruje stworzenie modelu dla kierunku studiów w portalu ElStudent. Atrybuty zostaną określone używając metody klasy models (należy je określić jako pola - fields). Są to na przykład: CharField - Pole na string, TextField - Pole na string - lepiej przystosowany do długiego stringa, ForeignKey - Pole z kluczem obcym do innego modelu, IntegerField - Pole na liczbę, BooleanField - Pole przyjmujące dwie wartości False - fałsz/true - prawda ImageField - Pole na zdjęcie, FileField - Pole na plik, DateTimeField - Pole na szczegółową datę i czas I wiele innych zdefiniowanych w dokumentacji framework a Dodatkowo na koniec została dodana reprezentacja naszego modelu. Dzięki temu między innymi w adminie, zamiast programme_object można ujrzeć jego nazwę co bardzo ułatwi jego identyfikacje. Powyższy przykład po zrobieniu migracji wprowadzi do bazy danych następujące polecenie: 15

17 CREATE TABLE programme ( "id" serial NOT NULL PRIMARY KEY, "name" varchar ( 30 ) NOT NULL, "usos_id" varchar ( 30 ) NOT NULL ); Warto dodać, że jak widać w powyższym przykładzie, framework dodaje własnoręcznie atrybut id będący kluczem głównym tabeli, jeżeli taki nie został zdefiniowany w modelu. 2.4 Modele projektu ElStudent Modele projektu ElStudent zaprojektowane są z uwzględnieniem wszystkich potrzeb aplikacji. Odpowiednie relacje pozwalają połączyć dane zapisane w różnych tabelach w spójną całość. 16

18 Powyżej zamieszczone zostały modele aplikacji UserProfile. Na samej górze przytoczony został wbudowany model frameworka Django - User. Jego atrybuty nie są dla nas wystarczające dlatego należy rozszerzyć klasę User, klasą UserProfile umieszczając unikalny klucz obcy do klasy User. Samo rozszerzenie użytkownika o klasę UserProfile nie było wystarczające, ponieważ należało w bazie umieścić dane, które posiada ta klasa jednak one wymagały własnych atrybutów, dlatego klasę UserProfile rozszerzono kolejnymi modelami. Model LoggedUser jest to model zawierający tylko zalogowanych userów. Poprzez dopisanie do modeli odpowiednich metod usuwających obiekty użytkowników przy wylogowywaniu i tworzących przy logowaniu. 17

19 Kolejny schemat modeli przedstawia nam aplikację programme odpowiadającą za kierunki projektu Django. Przez pole ManyToManyField w UserProfile wiemy do jakich kierunków należy dany użytkownik. Program sam w sobie zawiera tylko nazwę i id z systemu USOS, który jest jego unikalnym identyfikatorem. Oczywiście sam Programme to dla nas za mało. Pojawi się chęć w kierunkach zamieszczać posty, komentarze do tych postów, oraz pliki. Dlatego odpowiednio należy rozszerzyć te modele. Kolejny schemat pokazuje nam model dla aplikacji obsługującej nasze zajęcia. Działa on na tej samej zasadzie, z tą różnicą, że do Course czyli model reprezentatywny naszych zajęć powinniśmy umieścić informacje o semestrze i slug - unikalny identyfikator dla URL. Także dodać model dla Notatek. 2.5 ORM w Django ORM w Django należy używać za pomocą QuerySet. Są to polecenia umożliwiające nam odczytanie informacji z bazy danych, a wynik otrzymać w postaci obiektów. 18

20 Przetestować nasz QuerySet możemy za pomocą interaktywnej konsoli Django, a uruchomić ją możemy za pomocą: python manage. py shell Na początku należy zaimportować modele, które mamy zamiar użyć. Składnia importowania modeli czy też innych składowych danej aplikacji wygląda następująco: from nazwa_aplikacji. nazwa_pliku import nazwa_funkcji / zmiennej / klasy Aby uzyskać dostęp do wszystkich obiektów danego modelu należy użyć: Nazwa_Modelu. objects. all () Za pomocą get możemy uzyskać pojedynczy obiekt zamiast listy obiektów Nazwa_Modelu. objects. get ( atrybut = warto ść) Gdy chcemy zawęzić nasze poszukiwania możemy użyć filtra: Nazwa_Modelu. objects. filter ( atrybut = warto ść) W powyższym przykładzie należy importować modele dla zajęć i profilu. Następnie wyświetlić wszystkie zajęcia, po czym do zmiennej queryset przypisać profil użytkownika o id równym 1. Za pomocą tego profilu możemy wyświetlić wszystkie zajęcia do jakich użytkownik o id profilu równym 1 jest przypisany. Prócz wymienionych powyżej metod all, filter, get - QuerySet w Django posiada o wiele więcej metod co czyni go potężnym narzędziem do wyciągania informacji z baz danych. Są to na przykład: reverse - zwracane obiekty będą uporządkowane w odwrotnej kolejności, distinct - zwraca tylko unikalne obiekty bez duplikatów, values - zwraca słownik zamiast obiekt, select_related - odrazu przy wywoływaniu odczytuje wartości modeli odnoszonych przez klucze obce, raw - pozwala na użycie języka SQL w zapytaniu, 19

21 delete - usuwa dane z bazy danych, create - tworzy nowy obiekt i zapisuje go w bazie danych, save - zapisuje dany obiekt order_by - pozwala na sortowanie według podanego atrybutu 20

22 3. URL W każdym projekcie odpowiedni schemat adresów URL jest jak najbardziej pożądany. Django pozwala na bardzo łatwe dostosowywanie tychże adresów do swoich potrzeb. Aby tego dokonać dla danej aplikacji, potrzebny jest moduł python a zwany URLconf. Moduł ten jest czystym kodem języka python i łącze wzorce URL (wyrażane wyrażeniami regularnymi) do funkcji języka python - czyli naszych widoków. Adresy URL mogą być dowolnie krótkie, lub długie. Także dzięki wyrażeniom regularnym mogą być tworzone dynamicznie. 3.1 Działanie URL w Django Kiedy użytkownik wchodzi pod podany adres URL w swojej przeglądarce wysyła zapytanie do naszego frameworka. Zapytanie to obsługuje następnie algorytm: 1. Django odczytuje z ustawień jakiego modułu URLconf powinien użyć. 2. Następnie wczytuje ten moduł i z pliku urls.py znajduje zmienną urlpatterns. 3. Iteruje wartości zmiennej urlpatterns w celu przypasowania wysłanego w zapytaniu adresu URL do znajdujących się tam wyrażeń regularnych 4. Jeżeli framework przypasował odpowiedni wzorzec do zapytania to wykonuje widok przypisany do danego wzorca. 5. Jeżeli framework nie przypasował odpowiedniego wzorca do zapytania to zwraca użytkownikowi odpowiedni błąd. 3.2 Definiowanie adresów URL Poprzez definiowanie adresów URL tworzona jest mapa naszego serwisu. Adresy URL powinny być możliwie jak najmniej skomplikowane, ich nazwy powinny w jakiś sposób odnosić się do strony na której znajduje się użytkownik, a także być przyjazne SEO. 21

23 W powyższym przykładzie zdefiniowane są adresy URL dla aplikacji main_page. Zaczynając od zaimportowania odpowiednich widoków, następnie dla każdego adresu należy wprowadzić wartość do listy urlpatterns. Schemat definiowania pojedynczego adresu wygląda następująco: url ( r ' wyra ż enie_regularne ', widok, name =' nazwa ') Jeżeli jest to standardowy urls.py tworzony wraz z powstawaniem projektu, to: url ( r '^ $ ', views. home, name =' home ') przypasowany będzie do URL domena.com/. Ostatni rekord pokazuje nam możliwość definiowania dynamicznego adresu URL, w tym przypadku należy pobierać dowolny ciąg znaków w danym miejscu i do widoku przekazać go przypisanego do zmiennej key. 3.3 Przekierowywanie URL do aplikacji Przy większej ilości aplikacji, a co za tym idzie - widoków, dobrym rozwiązaniem jest przekierowywanie adresów URL do poszczególnych aplikacji. Unikniemy tym samym bardzo dużej ilości kodu w jednym pliku. Aby tego dokonać należy utworzyć odpowiednie pliki urls.py w aplikacjach, a następnie ja zaimportować do głównego pliku urls.py znajdującego się w katalogu głównym projektu. 22

24 4. Widoki Funkcja widoku (w skrócie widok) jest normalną funkcją języka python, przyjmującą bardzo ważny dla działania framework a argument - request, a zwracana odpowiedź trafia do użytkownika, który w swojej przeglądarce wszedł na odpowiedni adres URL wyzwalający ten widok. Argument request przekazuje nam wszystkie informacje jakie zostały wysłane wraz z zapytaniem. Na przykład można sprawdzić czy zapytanie wysłał zalogowany użytkownik, a jeśli tak to dodatkowo można odczytać konkretnie jaki. Odpowiedzią może być dosłownie wszystko, co może zwrócić funkcja języka python - strona HTML, przeniesienie na inną stronę, błąd, dokument XML, czy też obrazek itd. Widok powinien zawierać kod służący wygenerowania pożądanej przez nas odpowiedzi. Widoki należy zdefiniować w pliku views.py w katalogu danej aplikacji. 4.1 Definiowanie widoków Widoki to tak naprawdę w zależności od typu klasy, lub funkcje języka python przyjmujące jako argument wartość zapytania użytkownika i ewentualnie zmienne pobrane z URL. Wymagane w nich jest zdefiniowanie odpowiedzi HTTP. Powyżej zobaczyć można widok odpowiadający za aktywowanie konta użytkownika, po wejściu w link aktywacyjny czyli adres URL naszego projektu z odpowiednim kluczem wysłanym podczas rejestracji. Prócz atrybutu zapytania, przyjmuje drugi argument - jest to klucz podany w adresie URL. Należy zacząć od sprawdzenia czy użytkownik nie jest już czasem zalogowany - zalogowany użytkownik musi być aktywny więc widok ten w odpowiedzi przekieruje go na stronę główną. 23

25 Jeżeli użytkownik nie jest zalogowany należy pobrać profil użytkownika, z danym kluczem aktywacyjnym. W przypadku gdy nie ma takiego profilu zwracana jest użytkownikowi strona HTML pod nazwą 404.html - która to wyświetli błąd użytkownikowi. Jak profil z takim kluczem istnieje, trzeba pobrać dane o modelu użytkownika wbudowanego w framework i raz jeszcze sprawdzić - tym razem czy jest aktywny. W zależności od wyniku testu aktywować użytkownika i zwrócić HTML z komunikatem sukcesu, bądź przekierunkować użytkownika na stronę główną projektu. 4.2 Dekoratory Dekoratory pozwalają na korzystanie z różnych właściwości zapytania HTTP. W powyższym przykładzie dla widoku profile używane są dwa dekoratory. Pierwszy jest dekoratorem framework a. Zastrzega widok tylko dla zalogowanych użytkowników, w przypadku próby dostępu do widoku przez niezalogowanego użytkownika przekieruje go do URL mechanizmu logowania. Drugi jest dekoratorem sprawdzającym, czy użytkownik przeszedł autentykację z systemem USOS: Ten dekorator działa podobnie jak ten pierwszy - z tą różnicą, że test zdefiniować możemy sami. Inne dekoratory jakich możemy użyć to na przykład: require_http_methods - Widok zastrzeżony wyłącznie dla podanych jako argumenty dekoratora metod HTTP gzip_page - Pozwala na skompresowanie treści vary_on_headers/vary_on_cookie - Pozwala na controle cache owania 4.3 Widoki na bazie klas Widoki na bazie klas można użyć dzięki imporcie odpowiednich widoków generycznych. 24

26 W powyższym przykładzie należy importować generyczny widok TemplateView służący wyświetlaniu odpowiedniego szablonu w odpowiedzi. Wystarczy tylko zdefiniować zmienną template_view i przypisać jej wartość - czyli nazwę pożądanego szablonu. 25

27 5.Formularze 5.1 Standardowe formularze HTML Framework Django pozwala na swobodną i bezkonfliktową wymianę danych między serwerem a systemem za pomocą formularzy HTML. Oczywiście formularz taki musi być zdefiniowany prawidłowo, czyli: Być umieszczony między tagami <form>, a </form> Określać metodą jaką dane będą przesyłane Przesyłane dane muszą być prawidłowo obsługiwane przez odpowiedni widok W zależności od konkretnej strony zarządzanie formularzami jest łatwym, bądź trudnym zadaniem. Zależy to głównie od ilości formularzy na danej podstronie, a także ilości danych i ich typ. Konieczne jest wtedy: 1. Przygotowanie i zdefiniowanie takich formularzy, 2. Wyświetlenie ich na stronie, 3. Umożliwienie wprowadzania konkretnych danych użytkownikom, 4. Wysłanie ich na serwer, 5. Walidacja otrzymanych danych, 6. Podjęcie odpowiednich czynności w zależności od danych, 7. Wyczyszczenie formularzy, 8. Zwrócenie użytkownikowi stosownego komunikatu. 5.2 Formularze Django Mimo że framework Django dobrze współpracuje ze standardowymi formularzami HTML - posiada on własny mechanizm generujący takie formularze, co niesie z sobą wiele korzyści. Dzięki funkcjonalności mechanizmu formularzy Django proces tworzenia i obsługiwania formularzy jest zautomatyzowany i uproszczony, co więcej przesyłane dane są lepiej zabezpieczone. Formularze te obejmują trzy główne części tworzenia i stosowania standardowych formularzy: 1. Przygotowanie odpowiednich danych do konwersji 2. Konwersja danych do formy gotowej do wyświetlenia użytkownikowi jako HTML 3. Przyjmowanie i przetwarzanie danych otrzymanych z formularza użytkownika Rdzeniem całego tego mechanizmu jest klasa Form. 26

28 Podobnie jak model opisuje strukturę logiczną obiektu, jego metody, oraz reprezentacje. Również w podobny sposób jak pola modelu konwertują dane do bazy danych, tak pola formularzy Django konwertują dane do HTML. Pola formularzy są klasami samymi w sobie. Generują dane potrzebne do stworzenia formularza i przeprowadzają ich walidację po zatwierdzeniu formularza przez użytkownika. Podczas przetwarzania obiektu w Django, działa to na zasadzie: 1. Pozyskanie danych o obiekcie 2. Przekazanie go do szablonu HTML 3. Jego konwertacja do kodu HTML za pomocą zmiennej szablonowej Przetwarzanie formularza w szablonie odbywa się w bardzo podobny sposób z drobną różnicą - zwykle niepożądanym działaniem jest wyświetlanie pustego obiektu w szablonie. Inaczej ma się to w przypadku formularzy gdzie chcemy wyświetlić pusty formularz, aby umożliwić użytkownikowi jego wypełnienie i jest to w pełni pożądane działanie. 5.3 Tworzenie formularza Django Formularze można zdefiniować w pliku views.py w katalogu aplikacji do której będzie on przeznaczony. Tworzenie formularzy należy zacząć od ich zaimportowania. Następnie należy utworzyć osobną klasę dla każdego formularza jakiego chcemy stworzyć, a w atrybucie klasy podać typ formularza, powyższy przykład przedstawia standardowe formularze Django, stąd używamy forms.form aby użyć klasy Form. Do każdego formularza trzeba przypisać jego pola, które konwertowane będą na <input> w HTML. 27

29 Pola należy zdefiniować podobnie jak w modelach przypisując do zmiennych odpowiednie pola importowane z mechanizmu forms django, a są to na przykład: CharField - pole na niewielki tekst, TextField - pole na większy tekst, BooleanField - pole przyjmujące tylko wartości Prawda/Fałsz, ChoiceField - pole przyjmujące tylko wartości zdefiniowane w atrybucie pola, DateField - pole na datę, DateTimeFIeld - pole na datę szczegółową (zawierać może nawet setne sekund), FileField - pole na plik, Field - pole na adres , IntegerField - pole na liczbę całkowitą, FloatField - pole na liczbę rzeczywistą, Pola mogą przyjmować atrybuty. Niektóre atrybuty są ogólne jak widget użyty powyżej do określania prezentowania pola (w tym przypadku PasswordInput() sprawia, że wpisywany tekst nie będzie widoczny, jest to metoda stosowana dla celów poprawy bezpieczeństwa aby żadna osoba trzecia nie widziała co jest tam wprowadzane). Niektóre atrybuty są desygnowane wyłącznie dla wąskiej grupy pól, a nawet wymagane przez nie jak max_length dla pola typu CharField określający maksymalną długość łańcucha tekstowego. 5.4 Użycie formularza w widoku Aby użyć wcześniej zdefiniowany formularz należy wczytać go i do widoku. Widok zawierający formularz musi zwrócić użytkownikowi szablon. Wraz z szablonem formularz ten powinien przekazany być do zmiennej i do niego przekazany. W tym samym widoku można choć nie jest to wymogiem - zdefiniować logikę przetwarzającą dane zwrócone przez użytkownika za pomocą tego formularza. 28

30 Aby użyć formularza w widoku trzeba najpierw go zaimportować. Następnie należy przypisać go do reprezentującej go zmiennej i przekazać do szablonu. Powyższe akcje wystarczą do wygenerowania formularza jednak nie do walidacji i przetwarzania danych. Aby widok był w stanie przetwarzać dane z formularza trzeba ustawić aby przy każdym wywołaniu sprawdzał czy wraz z żądaniem nie przyszła metoda POST, lub GET. Jeżeli w zapytaniu będą przekazywane dane jedną z tych metod, należy przypisać je do odpowiedniego formularza, bądź kilku formularzy. Powyższy przykład widoku, sprawdza czy zapytanie nie zawiera danych przekazywanych metodą POST - jeżeli nie wyświetli pusty formularz, jeżeli tak dokona walidacji tych danych i sprawdzi w tym przypadku czy dane do logowania są poprawne. Jeżeli walidacja danych przebiegnie poprawnie i będą one prawidłowe, framework dokona autentykacji użytkownika i przekieruje go na stronę główną - jeżeli nie zwróci stosowany komunikat błędem. 5.5 Użycie formularza w szablonie Przekazany przez widok należy wyświetlić w szablonie zwracanym przez ten sam widok. Formularz można wyświetlić na kilka sposobów, nie jest określone, który jest najlepszy dlatego warto dostosować się do konkretnej sytuacji. 29

31 Powyższy przykład demonstruje użycie formularza Django (przekazanego pod zmienną loginform z poprzedniego przykładu) w szablonie. Należy pamiętać, że formularz Django nie generuje tagu <form> i zamykającego go </form>, oraz przycisku typu submit zatwierdzającego formularz - należy je więc dodać samemu. Formularz możemy wyświetlić jako całość umieszczając jego nazwy w podwójnych klamrach, bądź też każde pole osobno dodając do nazwy odwołanie do tego pola również w podwójnych klamrach. W powyższym przykładzie dodatkowo do wyświetlania form użyte zostały metody przypisywania im tekstu pomocniczego i klasy CSS. Można to uczynić tak jak tutaj w szablonie bądź też w atrybucie przy definiowaniu form. Dla użytkownika wynikiem umieszczenia naszych pól będzie odpowiednio wygenerowany kod HTML. Pole dla adresu będzie wyglądać następująco: Dzięki dodaniu metod definiujących teksty pomocnicze i klasy, możliwa jest spójna integracja z interfejsem graficznym: 30

32 5.6 Formularze na bazie Modeli Jeżeli celem formularza jest zapisanie danych do bazy danych warto zamiast standardowego formularza Django użyć ModelForm, który desygnowany jest do formularzy reprezentujących cały, bądź część modelu. Powyższy przykład pokazuje ten sam formularz co wcześniej z tą różnicą, że stworzony został na bazie modelu User. 31

33 Obie metody są poprawne, jednak mając możliwość lepszym rozwiązaniem jest użycie ModelForm, gdyż bardzo skraca on kod i ułatwia zapis do bazy. Problem pojawić się może jednak przy rozszerzaniu formularza o elementy spoza modelu. Jest to możliwe stopień zaawansowania tej operacji odbiera największą zaletę użycia ModelForm jaką jest czas i mała ilość kodu. Dodatkowo przy zapisie mogą pojawić się nieprawidłowości. 32

34 6. Szablony 6.1 Zmienne Zmienne w szablonach pozwalają na wyświetlenie danych przekazanych przez widok. Aby użyć zmiennych w szablonie warunkiem koniecznym jest ich zdefiniowanie w widoku i przekazanie do szablonu. Prócz ich wyświetlania można określać warunki ich wyświetlania, oraz styl w jakim zostaną wyświetlone. Dzięki tym operacją tworzą spójną całość w kodzie HTML. Zmienne do szablonów są przekazywane przez widoki wyświetlające dany szablon. Zmienną umieścić można w szablonie umieszczając ją w podwójnych klamrach. Oprócz wyświetlenia wartości lub reprezentacji zmiennej można się na przykład przy obiektach odwołać do ich atrybutów, w ten sam sposób co normalne odwoływanie w języku python czyli po kropce. Do zmiennych można dodać filtry dodając i nazwę filtry oraz jego wartość jeżeli takowy wymaga. W powyższym przykładzie użyty został zdefiniowany osobno filter dodający klasę CSS do zmiennej, jednak framework Django posiada też własne filtry jak na przykład: Default - Jego wartość będzie wyświetlana w przypadku braku zmiennej, Length - Zwraca długość wartości zmiennej, Filesizeformat - Zwraca rozmiar pliku 33

35 Oto efekt powyższego kodu widoczny dla użytkownika. Widok przekazał informacji do szablonu o imieniu i nazwisku użytkownika, jego kierunku i zdjęciu profilowym, a szablon odpowiednio to wyświetlił. 6.2 Tagi Tagi pozwalają na użycie warunków wyświetlania danych w szablonie. Tagi w szablonie umieszcza się podobnie jak zmienne, z tą różnicą, że wewnętrzny cudzysłów zamienić należy na znak procentu. Tagi pozwalają przeprowadzać operacje logiczne w szablonie. W powyższym przykładzie zostało zaprezentowane użycie tagów for i if - które działają i mają składnie identyczną do ich odpowiedników w języku programowania python, z tą różnicą, że wymagają tagów zamykających mówiących o tym gdzie kończy się ich działanie odpowiednio endfor i endif (szablon w przeciwieństwie do python a nie jest wrażliwy na intendacje). 34

36 7. Panel Administracyjny Panel Administracyjny tworzony jest wraz z powstawaniem projektu i zapewnia bardzo szybkie i wygodne zarządzanie danymi z bazy danych na podstawie modeli. Aby uzyskać dostęp do panelu admina należy udać się na adres strony projektu i dodać do URL głównego /admin. Potrzebna jest weryfikacja, którą przejść można tylko podając odpowiednie dane do logowania na użytkownika z uprawnieniami administratora. Stworzyć takiego użytkownika można za pomocą pliku manage.py: python manage.py createsuperuser 35

37 Początkowo tylko wbudowane modele framework a Django będą dostępne w panelu administracyjnym. By uzyskać dostęp do zdefiniowanych w aplikacjach modeli należy je zarejestrować w pliku admin.py w odpowiednim katalogu aplikacji: Rejestracje w pliku admin.py można dokonać za pomocą zaimportowania mechanizmu admin, następnie użycia metody register z modelem, który należy zarejestrować jako atrybut. 36

38 8. Django Rest Framework Django REST framework jest aplikacją napisaną dla framework a Django przeznaczoną do tworzenia aplikacji typu REST ( Representational State Transfer zmiana stanu poprzez reprezentacje, w skrócie REST). Głównymi zaletami używania tego typu aplikacji są: Interfejs umożliwiający swobodne przeglądanie naszych zasobów, Wiele metod autentykacji takich jak na przykład Auth1a czy OAuth2, Serializacja wspierająca zarówno ORM jak i pozostałe źródła danych, Duża swoboda w pisaniu kodu - można tworzyć aplikacje za pomocą zwykłych funkcji języka python, Duża popularność. 8.1 Serializacja Serializacja pozwala na konwersje danych do typów języka python, które następnie łatwo przedstawić w formacie JSON,XML i im podobnych. Serializacja pozwala także na deserializacje - czyli na przykład dane pozyskane w formacie JSON przedstawić za pomocą języka python co pozwala na ich łatwe przetwarzanie czy też zapis do bazy danych. Budowa serializatorów w Django bardzo przypomina formularze czy też modele. 37

39 Powyższy przykład pokazuje budowę serializatorów opartych na podstawie modeli. Potrzebny do tego będzie import modeli, których chcemy użyć i mechanizm serializacji z Django Rest Framework. Serializator jest klasą, która jako argument przyjmuje odpowiednią metodę serializacji w zależności od jego typu. ( w tym przypadku dla modeli należy użyć ModelSerializer) W podklasie Meta należy zdefiniować model którego chcemy użyć i jego pola (pola można zdefiniować kolejno umieszczając ich nazwy w tupli, bądź tak jak w przykładzie użyć selektora all by użyć wszystkich pól. Dodatkowo do serializacji można dodać własne pola i zdefiniować sposób pozyskiwania ich wartości - w przykładzie tym użyto innych serializatorów na podstawie modeli i użyto zagnieżdżenia by stworzyć kompleksowe REST Api z pełnymi informacjami na temat danego użytkownika. 8.2 Widoki na bazie serializatora Po zdefiniowaniu sposobu serializacji danych do stworzenia REST API potrzebne jest jeszcze zdefiniowanie odpowiedniego widoku. Widok ten musi pobrać odpowiednie dane i wskazać odpowiedni serializator. Dodatkowo może określać inne właściwości jak paginacja czy filtrowanie. Aby stworzyć widok na bazie serializatora potrzebne będą: Odpowiedni mechanizm dopasowany do typu serializatora - viewsets.modelviewset, 38

40 Modele na podstawie których stworzymy QuerySet i dzięki ORM będą przekazane dane do serializatora - User i UserProfile, Odpowiedni serializator - UserSerializer i UsersSerializer Widok ten stworzony będzie na bazie klasy przyjmującej jako atrybut odpowiedni mechanizm dopasowany do typu serializatora. Jako argumenty wymagane należy zdefiniować klasę odpowiedniego serializatora, oraz queryset na podstawie którego dane będą pobrane z bazy danych. Dodatkowo w powyższym przykładzie dla klasy UsersViewSet dodano: lookup_field - pole po którym będzie można uzyskać dostęp do obiektu, filter_backends - mechanizm filtrujący, filter_fields - pola które będą filtrowane W klasie UserViewSet natomiast zostały nadpisane metody pozyskiwania obiektów, tak aby zwracała ona przekonwertowane dane tylko o zalogowanym użytkowniku zamiast wszystkich. 8.3 Tworzenie URL dla REST Api Mając zdefiniowany widok dla REST API, pozostaje do niego przypisać odpowiedni adres URL. Dobrą metodą jest stosowanie nazw powiązanych z wyświetlanymi danymi, bowiem mając bardzo dużą liczbę tego typu aplikacji można łatwo się pogubić. Aby stworzyć URL dla REST Api utworzonych przez Django Rest Framework należy skorzystać z routers. Do tego będzie potrzebny dodatkowo mechanizm url i include z Django i odpowiednie widoki. Trzeba stworzyć router i rejestrować w nim te restowe API do których chcemy przypisać adres podając końcową część URL i wskazując na odpowiedni widok. 39

41 Następnie należy umieścić router w standardowym URL Django. 8.4 Interfejs Interfejs jest narzędziem pomocniczym dla programisty, bowiem umożliwia łatwy i czytelny przegląd danych. Dodatkowo pozwala przetestować działanie aplikacji za pomocą formularzy. Po stworzeniu URL do danego REST Api uzyskany został dostęp do interfejsu. Interfejs stworzony jest dla deweloperów, a jego głównym celem jest łatwy i przejrzysty podgląd. 40

42 Także umożliwia szybkie używanie metod HTTP w celu testowania poprawności działania. URL REST Api daje nam dostęp do listy wyników otrzymanych przez nasz QuerySet i serializator. Dodając do niego wartość pola identyfikacyjnego uzyskać możemy pojedynczy obiekt, także można użyć filtrowania czy też otrzymania prostego wyniku zamiast interfejsu. Chcąc dla przykładu otrzymać wynik zapytania w formacie json należy dodać:? format = json 41

43 9. Integracje 9.1 USOS Integracja z systemem USOS w projekcie ElStudent przeprowadzona została przy użyciu USOS Api. Do nawiązania połączenia użyto natomiast aplikacji języka python - rauth, która zawiera w sobie metody łączenia przez Oauth. Do połączenia potrzebne było wygenerowanie w systemie USOS klucza prywatnego i publicznego. Od użytkownika wymagane jest natomiast wyrażenie zgody na pobranie informacji i wpisanie jednorazowego tokena generowanego przez system USOS. Po nawiązaniu połączenia można pobrać dane następującą metodą: 42

44 Metoda ta jako argument pobiera adres odpowiedniego serwisu z USOS Api i na jego podstawie pobiera dane. Portal ElStudent pobiera przy autentykacji użytkownika z USOS: services/users/user - zwracający dane o użytkowniku, na jego podstawie przypisuje użytkownikowi jego Imię i Nazwisko, kierunek studiów, oraz sprawdza czy jest aktywnym studentem, services/courses/user - zwracający dane o zajęciach na które użytkownik jest zapisany w aktualnym semestrze, aby go do nich zapisać 9.2 Facebook Integracja z portalem Facebook ma na celu umożliwienie użytkownikowi stworzenie konta poprzez uwierzytelnienie w portalu Facebook zamiast standardowego formularza rejestracyjnego. 43

45 Na portalu Facebook trzeba stworzyć własną aplikację korzystając z strony dla deweloperów. Aby zintegrować aplikację z portalem ElStudent skorzystano z aplikacji dla frameworka Django - django-allauth mający zdefiniowany mechanizm uwierzytelniania i autentykacji dla wielu popularnych serwisów. Następnie wpisano odpowiednie klucze w ustawieniu aplikacji i umieszczono funkcję rejestracji/logowania przez portal Facebook: 9.3 SMTP Portal ElStudent wysyła do swoich użytkowników maile: Przy rejestracji - mail zawierający link aktywacyjny, Przy kontakcie - użytkownik po wypełnieniu formularza drogą mail ową może skontaktować się z administratorami Dane do połączenia z SMTP znajdują się w pliku settings.py 44

46 Podany wyżej przykład przedstawia część widoku odpowiedzialną za wysłanie maila z linkiem aktywacyjnym. Kolejno wczytuje on szablon dla wiadomości , umieszcza w nim klucz aktywacyjny dla użytkownika, definiuje temat wiadomości, wysyłającego i odbiorców, a następnie wysyła wiadomość. 45

47 Podsumowanie Umiejętne wykorzystanie framework a Django pozwala na zbudowanie zaawansowanej aplikacji internetowej w bardzo krótkim jak na to zadanie czasie. Zleceniodawcom takich serwisów bardzo często zależy na jak najszybszym wykonaniu zadania, gdzie Django ma zdecydowaną przewagę. To właśnie dzięki temu zdobywa swoją popularność. Choć wciąż ustępuje najbardziej popularnym rozwiązaniom jak Java czy.net, to grono jego zwolenników nieustannie się powiększa. Zauważyć można bardzo licznie tworzone społeczności entuzjastów framework a gdzie ludzie dzielą się swoim doświadczeniem, a także liczne powstawanie aplikacji stworzonych przez użytkowników. Potwierdzeniem powyższych słów może być użycie Django w największych i najpopularniejszych stronach internetowych, a także portal ElStudent. Projekt ElStudent mimo krótkiego czasu powstawania jest bardzo rozbudowanym portalem społecznościowym dla studentów. Obecnie korzystają z niego studenci uniwersytetu Adama Mickiewicza w Poznaniu, a planowana jest jego ekspansja na inne polskie uczelnie posiadające system USOS. 46

48 Bibliografia [1] docs.djangoproject.com - oficjalna strona framework a Django [2] - oficjalna strona języka programowania python [3] - oficjalna strona Django Rest Framework [4] The Definitive Guide to Django: Web Development Done Right (wydawnictwo Apress, ) - Adrian Holovaty, Jacob K. Moss [5] Learning Website Development with Django (wydawnictwo Packt Publishing ) - Ayman Hourieh [6] Python i Django Programowanie Aplikacji Webowych (wydawnictwo Helion ) - Jeff Forcier, Paul Bissex, Wesley Chun 47