Warnung! Beware! Uwaga!

[Rolf B]

Hallo MoaByter,

Erst werden die $_GETs und $_POSTs in Ass.Arrays umgewandelt

Das musst Du nicht tun. $_GET und $_POST sind bereits assozative Arrays, mit denen kannst Du ganz normal arbeiten.

Eine Übertragung von $_GET/$_POST Daten in eine eigene Datenstruktur kann natürlich trotzdem sinnvoll sein, wenn man aus einem geposteten Formularinhalt ein fachliches Objekt erzeugt und damit dann weiterarbeitet.

(mit htmlspecialchars($_POST[xy]) z.B., die Strings werden in base64 encodiert um Zeilenumbrüche u.a. zu schützen

Das sollst Du nicht tun. Die vom User erhaltenen Eingaben bleiben im Normalfall so, wie sie sind, und werden nur dann maskiert und behandelt, wenn es nötig ist. Also wenn sie in ein SQL Statement eingeflickt werden müssen oder wenn sie zum Browser zurückgeschickt werden. Vorher nicht. Wenn dein Benutzer Dir "Hallo <welt>" eingibt, dann möchtest Du das auch so speichern und verarbeiten, und nicht während der V Phase der EVA mit &lt und &gt herumfummmeln.

Eine base64-Codierung von Benutzereingaben zum „Schutz von Zeilenumbrüchen“ klingt nach einer schrägen Merkwürdigkeit oder einem schweren Missverständnis.

Langsam kloppen sich die Teile um die erste Stelle

session_start gehört nach vorne, ja.

Aber ob_start? Den braucht man seltener, als man denkt. Eine Verarbeitung nach EVA Prinzip besagt ja, dass Du alles, was Du zum Erstellen der Ausgabe brauchst, erstmal im Arbeitsspeicher zusammensuchst und dann zum Schluss an Hand der gesammelten Daten die Seite raushaust.

Aber das ist nicht immer effizient. Gerade bei großen HTML Seiten entsteht so eine ordentliche Latenz, weil der Server erstmal vor sich hin werkelt und den Browser warten lässt.

Wenn Du einen Webrequest verarbeitest, bist Du erstmal in eine "Findungsphase", wo Du rauskriegen musst, was genau zu tun ist. Musst Du das Form mit Fehlermeldung zurückweisen, musst Du die Seite im Format A, B oder C ausgeben, musst Du erstmal einen Login verlangen, etc.

Aber sobald das klar ist und nun "nur noch" Daten rauszuhauen sind, kannst Du auch damit anfangen. Wenn Du 100 Zeilen aus einer DB liest und als HTML Table ausgeben willst, dann ist es schlecht, das so zu tun:

• 100 Zeilen in ein Array lesen
• Aus 100 Zeilen HTML bauen und mit ob_start buffern
• Den Buffer rausrotzen

Wenn Du vor der Table Ausgaben machen willst, die Du erst erzeugen kannst wenn alle 100 DB Zeilen gelesen sind, OKAY, dann muss das. Aber auch dann kannst Du das gebaute HTML vermutlich sofort ausgeben und musst es nicht puffern. Das hat nämlich den Vorteil (sofern der Webserver nicht aggressiv puffert), dass der Browser das HTML vom Tabellenanfang schon vorliegen hat, während Du noch den Rest der Tabelle generierst. Das Parsen des HTML und das Erzeugen des HTML überlappen sich damit zeitlich, und für den Benutzer verringert sich die Wartezeit. Und Du brauchst weniger Serverspeicher, was auf einem unter Dampf stehenden Webserver immer eine gute Sache ist.

Rolf