nicht angemeldet
Hello,
Im Übrigen komme ich mit dem Script nicht zurecht da es (für mich) sehr unübersichtlich wirkt. Halte mich bitte nicht für Blöd aber ich muss es irgendwie nachvollziehen können wie alles zusammenläuft, wenn auch mehr Code dafür gebraucht wird.
Das Problem ist, dass Deine Begehrlichkeiten auch von Mal zu Mal rapide wachsen.
Aber das ist normal.
Am Anfang wolltest Du nur einfache Postparameter auf Existenz prüfen. Wenn ich mich recht entsinne, hast Du sie dafür gezählt. Dann hast Du eingesehen, dass einem da ja beliebige Parameter untergejubelt werden können, was natürlich nicht sein darf. Du hast also die Namen überprüft. Das ist war schon ein Fortschritt. Da war dann aber öfter ein Name darunter, der nicht erwartet wurde (PHPSESSID).
Und nun fing das Trilemma an. Es sollten keine unerwarteten Namen auftauchen aber auch alle erwarteten vorhanden sein. Dumm nur, dass die erwarteten nicht immer kommen, sondern im Falle von Session-ID und Radio/Check/Select-Elementen nur übermittelt werden, wenn es notwendig erscheint.
Und nun kam die strenge Prüfung auf den Plan.
Aber einen lesbaren Plan hast Du bisher noch nicht gezeichnet.
Ich hatte Dir einige Kriterien genannt, nach denen geprüft werden müsste, wenn man es so streng handhaben will (wogegen im Prinzip nichts einzuwenden ist). Die kann man aber nur entweder alle berücksichtigen oder die Prüfung ist nicht möglich.
Nun kamst Du noch mit Arrays als mögliche Parameter. Ich habe Dir eine Funktion gepostet, mit der auch Deep-Array-Parameter auf Existenz bzw. Erlaubtsein geprüft werden können und eine Funktion, mit der man aus einer "Expected-Liste" die notwendigen, aber nicht geposteten Parameter ergänzen kann und mit ihrem Default belegen kann.
Was jetzt erstmal fehlt, ist ein Plan (wie so oft).
Also bitte schreibe nochmal alle Parameter auf, die kommen dürfen, egal, ob sie jedes mal übermitelt werden, odr nicht, und zwar in der "Punktnotation" (Liest sich am leichtesten).
-
Dann schreib in einer Spalte dahinter, ob sie optional oder mandatory sind (M)
-
Dann schreib in einer weiteren Spalte dahinter, ob sie, wenn sie leer sind,
oder nicht übermittelt wurden (aber eben nicht required sind), angelegt und
mit einem Default aufgefüllt werden müssen (C) -
und in einer weiteren Spalte den Default (D)
#---
-
außerdem könnte auch noch eine Typprüfung stattfinden
die würde bei HTML und PHP dann feststelln müssen, ob der übermittelte
String feherfrei in den geforderten Zieltyp umwandelbar ist (T) -
Eine zusätzliche Format-Prüfung wäre denkbar (auch min. und max. Länge) (F)
-
Danach wäre ein Range-Check noch zweckmäßig (erlaubte Werte) (R)
#---
- es folt dann das Escaping für die Weiterverarbeitzng
Alle Prüfungen hängen in einem Regelwerk voneinander ab.
Erst wenn Du dich entschieden hast, welche Prüfungen in genau dieser Reihenfolge du furchführen willst (die ersten drei sind mandatorisch, wenn man sinnvoll prüfen will) und Deine Liste fertig hast, können wir effektiv weiterarbeiten.
Das Ziel ist aber nicht mehr fern.
Die Liste der erwarteten (Post-)Parameter kann später auch ausgebaut werden zu einer kompletten Formatbeschreibung eines Views und der dahinterliegenden Datenbindung. Das bedeutet, dass Du in Zukunft nur noch diese Liste erstellen müsstest und daraus automatisch die Tabellen für die DB und etliche Zeilen PHP für den Contoller sowie das HTML für den Browser erzeugen könntest.
Die sind dann sicherlich noch überarbeitungswürdig, aber man erspart sich eine Menge Arbeit und hat Übersicht.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
