Aplikacja webowa w Pythonie – Flask – Struktura większej aplikacji, czyli Blueprint – #7

Z każdym odcinkiem tutorialu nasza aplikacja coraz bardziej się rozrastała. Podłączyliśmy bazę, layouty i kilka routingów, które zaczęły powiększać plik views.py. Łatwo zauważyć, że z każdą następną linijką, staje się on coraz mniej czytelny. Wraz z rozwojem apki, nasze routingi przestaną wyglądać tak:

…a zaczną osiągać wielkości nawet kilkuset wersów. Powalczmy więc z tym zanim będzie za późno :)

Blueprinty

Zacznijmy od wprowadzenia kolejnego flaskowego pojęcia – blueprintu. Dokumentacja mówi, że:

Flask uses a concept of blueprints for making application components and supporting common patterns within an application or across applications.

oraz:

A blueprint in Flask is not a pluggable app because it is not actually an application – it’s a set of operations which can be registered on an application, even multiple times.

Nie jest to najbardziej jasna definicja na świecie, ale można się domyślić, że blueprinty pozwalają nam zaimplementować pewną modułowość i definiować zbiór operacji, do których będziemy się odwoływać w aplikacji.

Podzielmy views!

Blueprinty są bardzo przydatne, gdy views.py zacznie za bardzo się rozrastać. W naszym pliku mamy póki co jedną dużą funkcję, database_posts() – spróbujmy ją wyodrębnić.

W folderze głównym hello_world utwórz plik database_posts.py i uzupełnij go treścią odpowiedniego routingu z views.py (usuwając ją z pierwotnej lokalizacji), czyli:

Na początku pliku zaimportuj odpowiedni pakiet z flask i zdefiniuj nowy blueprint:

To właśnie db_posts_blueprint będzie jego nową nazwą. Pozostaje jeszcze edycja routingu, aby nie odwoływać się do aplikacji, tylko samego blueprintu:

…oraz zarejestrowanie nowo utworzonej części aplikacji w views.py:

Na początku database_posts.py zaimportuj jeszcze niezbędne pakiety:

I uruchom program.

Działa? Prawdopodobnie nie :)

Zapomnieliśmy edytować linki w base.html oraz w database_posts.html, które prowadziły do funkcji database_posts – “mądry” Flask podpowiada nam, na co powinniśmy je zmienić:

oraz podwójne:

Po podmienieniu url_for na właściwą konstrukcję, aplikacja powinna śmigać tak jak wcześniej – na froncie oczywiście nic się nie zmieniło, ale opanowaliśmy rozrastający się backend, co na pewno pomoże nam w przyszłości :)

Inne podejście do modułowości

Jeżeli nasza aplikacja robi się naprawdę spora i chcielibyśmy, aby nasze blueprinty były osobnymi modułami, możemy jeszcze trochę zmodyfikować strukturę aplikacji.

Zawartość database_posts.py, który wcześniej znajdował się w hello_world, przenieśmy to __init__.py, umieszczonego w strukturze hello_world/blueprints/db_post_blueprint, a database_posts.py usuńmy. Wtedy w views.py wystarczy zmienić jedną linijkę ( from .blueprints.db_posts_blueprint import db_posts_blueprint), aby aplikacja działała poprawnie.

Zauważ, że tego typu rozwiązanie daje Ci o wiele więcej możliwości. Możesz zdefiniować własne template’y czy pliki statyczne, które zostaną wykorzystywane jedynie w konkretnym blueprincie. Będzie to przydatne na przykład w sytuacji, gdy nasza apka posiada front widoczny dla każdego i panel administratora, do którego mogą dostać się jedynie zalogowani użytkownicy.

Powiedzmy, że chcemy, aby nasz panel administratora (czyli database_posts) znajdowało się w całości w blueprincie db_posts_blueprint. Jak to powinno wyglądać i działać?

Najpierw struktura:

W folderze db_posts_blueprint stworzyłam dwa foldery: posts_static i posts_templates. W posts_templates powstał jeszcze jeden folder db_posts_blueprint i dopiero w nim umieściłam index.html. Dlaczego tak? Wyjaśni nam to dokumentacja Flaska:

The reason for the extra admin folder is to avoid getting our template overridden by a template named index.html in the actual application template folder.

Po prostu nie chcemy, aby jakiekolwiek pliki ze sobą kolidowały – nawet takie o identycznych nazwach.

Kodowanie zacznijmy od pliku __init__.py w naszym blueprincie. Jak można zauważyć na screnshocie, zmieniły się dwie rzeczy – definicja blueprintu oraz routing. Pierwsze z nich wzbogaciło się o informację o folderach:

A drugie w odpowiedni url:

Resztę pozostawiamy bez zmian :)

Czas na views.py – musimy zmienić wywołanie blueprinta, aby działało, gdy znajduje się on w osobnym folderze (jeśli nie zrobiliśmy tego wcześniej):

Następnie zajmijmy się wyglądem – weźmy pod uwagę index.html w blueprincie. Usuńmy database_posts.html (nie będzie już potrzebne), a jego treść, w połączeniu z bazową, przenieśmy do index.html:

Póki co nie odwołujemy się w nim do base.html, tylko hardkodujemy całość (załóżmy, że nasz panel admina będzie miał osobną bazę, którą zdefiniujemy w przyszłości).

Interesująca jest ta linijka:

Jest ona odwołaniem do folderu statycznego blueprintu i pozwala zdefiniować własne style tylko dla niego. Treść style.css (znajdującego się w posts_static) wygląda obecnie tak:

Zmieniając tylko kolor tła na szary (ale wystarczy na potrzeby testu).

Pora na sprawdzenie, czy wszystko działa jak trzeba – powinno :)

Tego typu podejście sprawdza się przede wszystkim przy nieco większych aplikacjach, ale gdy chcemy oddzielić od siebie części serwisu, również możemy z niego skorzystać. Modyfikacja nie jest bardzo skomplikowana (szczególnie, gdy dopiero zaczynamy), a bardzo pomaga uporządkować kod i sprawia, że łatwiej się w nim później zorientować. Jednym słowem – warto :)