Ten post powstał na życzenie 
Mój przyjaciel poprosił mnie, abym napisała i wdrożyła bardzo prostą aplikację (choć słowo aplikacja może być nad wyrost, będę go jednak używać) napisaną z użyciem Flask’a.
W dodatku poprosił, o omówienie budowy powstałej aplikacji. Wygodny jest prawda 
Chciał zrozumieć podstawy tego freamwork’a.
Mimo, że nie miałam do tej pory styczności z Flaskiem, zgodziłam się.
Jestem bardziej obeznana w budowie aplikacji webowych - i jak się okazało koła nikt nie wymyślił tutaj od nowa. Działa na podobnych zasadach jak freamworki z innych języków np. Lumen od Laravel’a dla PHP.
Flask
Flask jak podaje wikipedia to mikrofreamwork aplikacji webowych napisany w języku python. Muszę przyznać, że jest dość przyjazny. Ma też sporo bibliotek rozszerzających jego działanie zagregowanych na pypi.org. Silnikiem generowania szablonów użytym we Flasku jest Jinja.
Ten post będzie bazował na przykładzie jaki zamieściłam na githubie: Look And Say with flask. Samą sekwencję Look And Say omówiłam w swoim poście Look and Say Sequence.
Wpierw jednak należy przytoczyć podstawy podstaw, jak działa sama aplikacja webowa.
Aplikacja webowa - podstawy
W każdej aplikacji webowej, niezależnie w czym i jak zostanie napisana, możemy wyróżnić podstawowe składowe: KLIENTA i SERWER, a także takie akcje jak: prezentacja danych i przetwarzanie danych.
W zależności od przeznaczenia i architektury aplikacji powyższe akcje będą realizowane w różnych miejscach.
-
Prezentacja: Do tej części zaliczymy pliki
.html,.cssw tym.scssi w pewnym stopniu.js. Jak nazwa wskazuje, zaliczone zostaną tutaj te elementy, które pozwolą nam wyświetlać dane, ale też zebrać dane od użytkownika. W tej warstwie następuje interakcja użytkownik -> aplikacja. -
Przetwarzanie: W zależności od budowy, dane mogą być przetwarzane w
.js, ale też wysłane na serwer i przetworzone w języku skryptowym np.pylubphp. Następuje tutaj też obsługa przygotowania danych w taki sposób, by były one później zrozumiałe dla klienta lub dla serwera. - Dane: Obsługa danych np. na bazie danych.
Można wyróżnić model, gdzie zarówno prezentacja jak i przetwarzanie będzie odbywało się po stronie klienta, natomiast po stronie serwera pozostanie jedynie obsługa bazy danych - i ten model jest obecnie najczęściej spotykany. Plusem takiej architektury jest odciążenie serwera od zadań przetwarzania danych.
Drugi model, starszy, polega na przetwarzaniu danych po stronie serwera, natomiast po stronie klienta odbywa się tylko prezentacja danych.
W trzecim modelu przetwarzanie będzie się odbywało zarówno po stronie klienta, jak i po stronie serwera.
Wracając do aplikacji “Look And Say with flask”, składa się ona z dwóch warstw: prezentacji odbywającej się po stronie klienta oraz przetwarzaniu danych realizowanych po stronie serwera.
Schemat działania aplikacji jest prosty. Użytkownik w przeglądarce podaje dwie liczby, które są niezbędne do obliczenia sekwencji look and say. Dane te z formularza wysyłane są na serwer, gdzie zostają przetworzone w funkcji Look and say, a następnie wynik zwracany jest z powrotem do przeglądarki.
Składowe aplikacji
W aplikacjach dąży się do rozdzielenia poszczególnych funkcji aplikacji na składowe, tak aby po pierwsze bardziej móc nad nimi “zapanować” w miarę rozrostu aplikacji, oraz by poszczególne elementy móc wykorzystywać kilkukrotnie, zarówno w ramach samej aplikacji, jak też kopiując je do innych aplikacji.
Budowa aplikacji będzie składać się w moim przypadku z katalogów i plików:
-
static/css - W folderze
staticbędą znajdować się wszystkie pliki statyczne typu.css,.js,images. W tej przykładowej aplikacji jest jedynie.css -
templates - gdzie mamy wydzielony kod HTML podzielony na plik główny szablonu odpowiedzialny za prezentację
index.htmloraz składowe zamieszczone w katalogucomponents. - app.py - główny plik, odpowiedzialny za naszą aplikację.
- lookAndSay.py - plik odpowiedzialny za obliczenie danych na serwerze.
Działanie aplikacji
Rozrysujmy co z czym jest powiązane:
Czarna strzałka na powyższej grafice określa w jaki sposób dane podane przez użytkownika są przekazywane między poszczególnymi warstwami. Z prezentacji do prztwarzania na serwerze przesyłane są metodą POST.
Niebieską strzałką zaznaczona jest droga odpowiedzi, aż do części oznaczonej jako result.html, gdzie dane są wyświetlane jako wynik operacji wykonywanych na serwerze. Z serwera zwracana jest lista przypisana do zmiennej result, przez którą dzięki Jinja wykonywana jest loopa z wyświetleniem wyniku, dla każdej z interacji.
Szarą strzałką oznaczyłam, te elementy, które są załączane do pliku index.html i które są ściśle odpowiedzialne za prezentację aplikacji użytkownikowi.
Niestety przyjaciel stwierdził, że jest to za trudne. Za dużo powiązań łączących pliki. Chciałby jak w pandoc’u, wpisuje funkcję np. lookAndSay i na tej podstawie by był generowana cała aplikacja, że wszystkimi powiązaniami. Niestety, a może i stety - póki co nie jest to możliwe. Przynajmniej Frontednowcy wciąż mają pracę .