Flask view functions und Messaging als Programmierparadigma

Berlin, Tue, 04 Feb 2020 11:11:05 +0100 last edited: Wed, 23 Mar 2022 13:30:32 +0100

Zum Behandeln von HTTP Anfragen muss man fÃ¼r Flask jeweils Eine Funktion
schreiben die eine Anfrage auf eine konkrete Ressource behandelt.
Diese Funktionen werden oft View-Functions genannt.
Ich finde den begriff treffend und werde ihn daher auch benutzen.

Eine View-Function sollte m.E. immer eine Art von Abfrage behandeln.
Negativbeispiel sind hier die viel zu findenden Beispiele zum Handhaben von
Formularen.

 @app.route("/login", methods=["GET", "POST"])
 def login():
     if request.method == 'POST':
         username = request.form['username']
         password = request.form['password']
         if password == username + "_secret":
             id = username.split('user')[1]
             user = User(id)
             login_user(user)
             return redirect(request.args.get("next"))
         else:
             return abort(401)
     else:
         return Response('''
         <form action="" method="post">
             <p><input type=text name=username>
             <p><input type=password name=password>
             <p><input type=submit value=Login>
         </form>
         ''')

Die erfahrung zeigt, dass mangels anderer Beispiele diese Beispiele schon aus
pragmatischen ErwÃ¤gungen (get things done) Ã¼bernommen werden. Dadurch wird
weiter ausufernden Verzweigungen innerhalb einer View-Function vorschub
geleistet. Es entsteht schnell schwer lesbarer, und noch unÃ¼bersichtlicher und
damit schwerer testbarer Code. Resultat, Ã¤nderungen werden irgendwann schon
allein deshalb vermieden, weil man fast immer etwas kaputt macht.

Das obige Beispiel lÃ¤sst sich recht leicht umbauen:

 @app.route("/login", methods=["POST"])
 def login():
     username = request.form['username']
     password = request.form['password']
     if password == username + "_secret":
         id = username.split('user')[1]
         user = User(id)
         login_user(user)
         return redirect(request.args.get("next"))
     else:
         return abort(401)
  
 @app.route("/login", methods=["GET"])
 def get_login_form
     return Response('''
     <form action="" method="post">
         <p><input type=text name=username>
         <p><input type=password name=password>
         <p><input type=submit value=Login>
     </form>
     ''')

Das schaut schon besser aus ist fÃ¼r mich aber noch nicht wirklich befriedigend.
Es verleibt ein
if .. else
Block in der login Funktion die
request
und
redirect
integriert. Das ist eine Verletzung vom
IOSP.

Ralf Westphal hat hierzu ein sehr schÃ¶nes ebook verfasst:
Messaging as a Programming Model.
Nach meinem VerstÃ¤ndis befindet sich eine Flask View-Function am Stamm des von
Ralf Westphal in diesem Buch skizzierten Baums der Funktionsaufrufe.
Oder wenn man sich das in Schichten vom Aufruf des Programms bis zu den ganz unten liegenden Operationen vorstellt stellt die View-Function einen Teil der
OberflÃ¤che dar.
Wichtig bei den unten liegenden Operationen ist, dass sie dem IOSP oder noch
besser dem
Prinzip der gegenseitigen Nichtbeachtung (PoMO) folgen.

Aber ich interessiere mich gerade nicht fÃ¼r die BlÃ¤tter, wie Herr Westphal die
Operationen in seinem Buch nennt, sondern fÃ¼r die Integrationsteile.

Kleine Abschweifung zum Thema bessere Ausbildung von FachkrÃ¤ften: spoiler

Hier liefert mir das Buch von Herrn Westphal einen guten Ansatz, der mir aber
so noch nicht ausreicht. SchÃ¶n zum Entwerfen auf Papier, alles klar, aber leider
etwas zu Abstrakt.
Aber er bezieht sich auf Steve Bate mit dem der zu dem Thema auch eine
Korrespondenz gefÃ¼hrt hat.
Steve Bate hat zu Messaging as a programming model
einen sehr langen und guten Blog Artikel geschrieben, zu dem es auch einen
zweiten Teil gibt.

Hier bekomme ich LÃ¶sungsansÃ¤tze fÃ¼r das Problem.

Ich vermute man kann in der View-Function sehr gut eine Pipeline nach dem
Pattern Pipes and Filters
integrieren. Wir geben aber zwei unterschiedliche Flask-Respnse Objekte zurÃ¼ck.
Entweder, wenn der Login erfolgreich ist einen Redirect oder einen Abort.
Ich sehe zwei Herangehensweisen fÃ¼r das Problem.

Es muss einen Filter geben, der aus dem egebnis der Login PrÃ¼fung einen der
beiden Responses erzeugt. Damit muss dieser dann aber wieder wisse Ã¼ber die Kontrolllogik fÃ¼r die empfangende Nachricht und das Response Object haben.
Damit wÃ¤re mein Problem nicht gelÃ¶st sondern nur in eine Tiefere Ebene
Verschoben.

Es muss einen Filter geben der die Login Nachricht bei Fehlschlag an
einen Filter weiter leitet der den Response fÃ¼r einen Abort und bei
Erfolg an einen Filter weiter leitet der den Response fÃ¼r einen Redirect
erzeugt.

Ansatz 1 ist vor allem besonders Unbefriedigend, da er auch noch gegen
"Simple is better than complex." aus
"The Zen of Python" verstÃ¶ÃŸt.

Das mÃ¼ssen wir bei LÃ¶sung zwei zar auch hinnehmen. Aber der Ansatz 1 ist nicht
einfach nur komplexer, denn er lÃ¶st das Problem nicht in unserem Sinne.
Er verkompliziert die Dinge auch. Damit ist
"Complex is better than complicated." aus
"The Zen of Python" ebenfalls
verletzt.

Die gestiegene KomplexitÃ¤t fÃ¼r ansatz 2 wÃ¤re ein notwendiges Ãœbel.
Ich wÃ¼rde sogar behaupten, dass es den Ansatz
"Flat is better than nested." aus "The Zen of Python" unterstÃ¼tzt.

Ich kann damit nÃ¤mlich definitiv stark verschachtelte (tiefe) Verzweigungen
leichter vermeiden.

Steve Bate bezieht sich in seinem blog Ã¼brigens auf das Buch
"Enterprise Integration Patterns: Designing, Building, and Deploying
Messaging Solutions" von Gregor Hohpe und Bobby Woolf
(Link zum buch auf smile.amazon.de).

Auch Sehr Informativ in diesem Kontext dÃ¼rfte "Patterns fÃ¼r Enterprise
Application-Architekturen" von Martin Fowler
(Link zum Buch auf smile.amazon.de) sein.

Techlevel-Dev Development Software-Architektur Python Messaging als Programmierparadigma