nicht angemeldet
Hi!
Für den Rest werde ich mich wohl erstmal über Lazy-Fetch und die Verwendung der von dir verlinkten Interfaces informieren müssen, momentan geht das noch deutlich über meinen Horizont hinaus.
Lazy-Irgendwas bedeutet, dass das Programm "zu faul" ist, dieses Irgendwas sofort zu tun. Stattdessen wartet es damit, bis es wirklich notwendig ist, also wenn eine konkrete Anforderung nach den Daten besteht. Wenn es Glück hat, nimmt der Programmfluss einen anderen Verlauf, bei dem die Daten doch nicht benötigt werden, und es hat sich die Arbeit gespart.
Bei mir beginnt die Ausgabe eines HTML-Dokuments mit dem Doctype und <html> usw. Da ist also noch einiger Abstand zwischen der Erzeugung des Flags $account_selected_to_delete und der Auswertung in der Ausgabe.
Ja. Jain. Bei mir auch.
Was ich bisher nicht erwähnt habe, ist dass die hier erzeugten Ausgaben zunächt in einem Ausgabepuffer landen und später an der richtigen Stelle im Dokument eingefügt werden.
Dann wäre das Einschalten des Ausgabepuffers die erste Amtshandlung der Ausgabelogik, und das stünde dann zwischem dem Erzeugen des Flags und seiner ersten Anwendung. Gut, das ist jetzt auch kein großer Abstand, aber wir nehmen einfach mal an, dass das Programm später erweitert wird und sich der Abstand dadurch vergrößert. Oder dir fällt auf, dass die Abfrage doch schon weiter oben benötigt wird, oder oder oder. Jedenfalls willst du doch eine klare Trennung, auch um damit Erfahrung zu sammeln, und da kannst du ruhig mal konsequent sein, auch wenn dir das redundant vorkommt. Dieser kleine Zusatzschritt bringt deinen Server nicht um - er wird nicht mal messbar sein.
Ich habe also ein Template mit einigen einfachen Platzhaltern, die nur ersetzt werden müssen. Einer dieser Platzhalter befindet sich im Body und wird durch den Output meiner „Ausgabe“ ersetzt. Blöde Idee?
Nicht unbedingt. Solange es nachvollziehbar, übersichtlich und wartbar bleibt, sollte das o.k. sein. Wie bewertet man aber diese Kriterien? Eine Formel gibt es dafür nicht, aber mit zunehmender Erfahrung wirst du ein Bauchgefühl dafür entwickeln.
Ich glaube, ich muss jetzt mal noch umfassender verraten, wie ich eigentlich vorgehe:
Zusammenfassend, deine Ausgabe beginnt also damit, gepuffert den Hauptinhalt zu erzeugen, der später an der gewünschten Stelle in den Rest der Seite eingefügt wird.
Ist das komplett unsinnig?
Nö. Das könnte im Gegenteil sogar vorteilhaft, weil du damit das Wesentliche zuerst machst und "der unbedeutende Rest" irgendwo hinten steht. Allerdings erhöht sich damit auch die Komplexität wieder ein wenig, einerseits durch die zusätzliche Pufferung und andererseits durch die nicht mehr lineare Reihenfolge beim Erstellen der Ausgabe. Doch das würde ich jetzt nicht überbewerten wollen, weil es mir nicht als ein wirklicher Nachteil erscheint.
Wenn ich so darüber nachdenke, wäre es vermutlich zumindest ein Ansatz, das Konzept aus der Template-Datei konsequent anzuwenden und die „Datei für’s Seitenspezifische“ möglichst unter der Verwendung der von dir verlinkten alternativen Syntax nach Eingabe und Verarbeitung zu trennen. Klingt das vernünftig?
Du meinst, statt einen großen, mehrzeiligen String mit Platzhaltern zu erstellen, die in einem zweiten Schritt mit printf() ersetzt werden, lieber gleich HTML erzeugen, in das die Werte eingefügt werden? Hat zumindest den Vorteil, dass ein Editor oder eine IDE das HTML als solches erkennen können, und dafür Syntax-Unterstützung anbieten können. Wie es mit der Übersicht aussieht, muss man sehen. Einerseits kommt der die Ausgabe eines Wertes genau an die Stelle, an der er stehen soll, andererseits ist bei der Platzhaltergeschichte das Drumherum besser lesbar, weil da nur ein kleines %s steht und der HTML-Code nicht durch PHP-Code zerrissen wird. Da muss man fallweise entscheiden, was der bessere Kompromiss ist. Wenn so ein HTML-Tag mit mehreren Attributen drin mehrfach durch PHP-Code unterbrochen wird, bekommt nicht nur die Syntaxunterstützung ein Problem, die Teile auseinanderzuhalten, auch das Auge des Betrachters. Sowas würde ich dann eher einzeln einem printf() zum Zusammenbauen übergeben. Nur-HTML-Blöcke stehen besser für sich zwischen ?> und <?php.
Entschuldige bitte, wenn ich so „unmündige“ Fragen nach richtigem und falschem Vorgehen stelle, aber ich habe das Gefühl, noch einige grundlegend falschen Vorstellungen über eine ordentliche Struktur zu haben …
Entwicklungspotential zu haben ist für mich kein Grund, um Entschuldigung zu ersuchen. Das hat doch jeder.
Vor allem frage ich mich immer wieder Folgendes: Im Moment reden wir nur über die Ausgabe von HTML - ein Kontext, in dem es mich auch überzeugt, dass eben PHP- und HTML-Code nicht völlig zu trennen sind. Aber angenommen (rein hypothetisch, habe ich nicht vor), ich wollte mir genauso die Möglichkeit offen halten, zur Ausgabe beispielsweise ein Bild zu erzeugen. Das würde doch bedeuten, dass das, was mein Verarbeitungs-Part an die Ausgabe weitergibt, völlig frei von jeglicher HTML-Auszeichnung sein müsste. Allerdings ist doch genau das scheinbar weder sinnvoll noch unbedingt notwendig.
Ein Bild hat keinen HTML-Code. Aber wenn du es erst erzeugen musst, dann doch aus dem Grund, dass es aus mehreren Teilen zusammenzusetzen ist - beispielsweise ein Hintergrund und individuelle Schrift drauf - oder durch Bearbeitung aus einem anderen Bild entstehen soll - wie zum Beispiel bei einer Verkleinerung. Auch hier kann man das EVA-Prinzip anwenden, wenn es sich lohnt. Der größte Teil wird jedoch der Verarbeitung zuzuordnen sein und die Ausgabe beschränkt sich auf ein oder mehrere header()-Aufrufe und ein imagejpeg() und Konsorten. Da würde ich einfach nur die einzelnen Bildverarbeitungsschritte kennzeichnen und wenn es hilfreich erscheint Berechnungen in Funktionen auslagern.
Ich hoffe, ich rede keinen völligen Blödsinn - bin in dieser Hinsicht etwas verwirrt.
Nun, dann hoffe ich doch, noch ein paar weitere Klarheiten beseitigt zu haben. (Das hab ich grad mit einem schelmischen und einem ernsten Auge gesagt, denn je weiter man in den Ozean abtaucht, desto mehr erkennt man von seiner unendlich erscheinenden Komplexität und dem eigenen Unvermögen, alles ergründen zu können.)
Lo!