Schlüselparameter, Zweckbestimmung und Umgang

Webanwendungen die über Parameter gesteuert werden

Schlüsselparameter und Zweckbestimmung

Webanwendungn werden gewöhnlich über Parameter gesteuert. Was heißt das? Nun, stellen wir uns vor, wir haben eine Tabelle und wollen dem Besucher eine Listenansicht ermöglichen oder ein Download. Mit einer solchen Aufgabenstellung wird sofort klar, daß je nach Parameter ein anderer Inhalt an den Browser ausgeliefert wird und ggf. auch ein von text/html abweichender Content-Type. Eine diesbezügliche Kontrollstruktur sähe in Perl so aus:

if( param('list') ){ # erzeuge Listenansicht } elsif( param('download') ){ # header Content-Type: text/csv # CSV-Datei senden }

Beachte: Es können, je nach Aufgabenstellung können da ggf. weitere Parameter hinzukommen. Das obenstehende Beispiel macht die Zweckbestimmung und Verwendung von Schlüsselparametern deutlich die deswegen so heißen weil das bloße Vorhandensein eines solchen Parameters den Programmverlauf bestimmt. Schlüsselparameter werden also im Boolschen Kontext verwendet und sollten keine Nutzdaten überbringen. Im nächsten Abschnitt geht es um mögliche Probleme bei Nichtbeachtung dieser Grundregel.

Nutzdaten und Schlüselparameter

Unter Nutzdaten soll verstanden werden, daß diese über einen Parameter in die Anwendung hineingereicht werden. Beispielsweise als year=2022 oder month=3. Bleiben wir bei diesem Beispiel und nehmen mal an der Benutzer wählt zunächst das Jahr und auf der Folgeseite einen Monat. Wenn wir jedoch so vorgehen daß wir zuerst den Parameter year abfragen und dann den Parameter month, haben wir ein Problem, denn es gibt ja auch beide Parameter gleichzeitig. Untenstehende Kontrollstruktur geht schief:

if( param('year' ){ # Fall 1 # zeige die Monate die zu eineem # bestimmten Jahr gehören } elsif( param('year') and param('month') ){ # Zeige Inhalt für ein bestimmtes Jahr # und einen bestimmten Monat }

Denn auch wenn beide Parameter im Request gesendet werden, entscheidet sich die Kontrollstruktur für den Fall 1 weil ja das Jahr allein schon die Bedingung erfüllt. Idee: Wir drehen die Kontrollstruktur einfach um!

if( param('year') and param('month') ){ # Zeige Inhalt für ein bestimmtes Jahr # und einen bestimmten Monat } elsif( param('year' ){ # zeige die Monate die zu eineem # bestimmten Jahr gehören }

Diese Kontrollstruktur erfüllt ihren Zweck. Mit der gleichzeitige Nutzung von Schlüsselparametern zu Übertragung von Nutzdaten begehen Sie jedoch einen systematischen Fehler der sich dann zeigt, wenn weitere Parameter ins Spiel kommen. Nehmen wir einmal an es soll ein bestimmtes Image ausgegeben werden, welches zu einem bestimmten Jahr und zu einem bestimmten Monat gehört. Ein Versuch:

elsif( param('img') and param('year') and param('month') ){}

Und das geht gründlich in die Hose. Nämlich derart daß Sie stundenlang am Grübeln sind warum das gewünschte Image nicht im Browser erscheint. Weil sich die Kontrollstruktur bereits beim Parameter year UND month entschieden hat etwas anderes zu tun.

Fazit

Trennen Sie Parameter die Nutzdaten enthalten von Parametern die als Schlüsselparameter dienen. Wenn Sie param('year') oder param('month') namentlich an einer anderen Stelle im Programmverlauf benötigen, vermeiden Sie es, diese Namen als Namen für Schlüsselparameter zu benutzen. Betrachte untenstehende Kontrollstuktur, sie ist selbsterklärend:

# ohne Parameter werden die verfügbaren Jahre gezeigt # die angeklickt werden können. Per Klick wird ein # bestimmtes Jahr in den Request gegeben und # daraufhin die zum Jahr verfügbaren Monate gezeigt if( param('listmonths') ){} elsif( param('listimages') ){ # zeigt alle zu Jahr und Monat gehörigen # Images } elsif( param('showimage') ){ # Zeigt ein bestimmtes Image }

Gut zu sehen: Die Namen der Parameter year und month kommen in dieser Kontrollstruktur gar nicht vor. Die Kontrollstruktur enthält nur aussagekräftige Schlüsselparameter im boolschen Kontext.


Datenschutzerklärung: Diese Seite dient rein privaten Zwecken. Auf den für diese Domäne installierten Seiten werden grundsätzlich keine personenbezogenen Daten erhoben. Das Loggen der Zugriffe mit Ihrer Remote Adresse erfolgt beim Provider soweit das technisch erforderlich ist. s​os­@rolf­rost.de.