wo php in html einbinden?
0 
dedlfix
0 0
wo php in html einbinden?
Der MartinGuten Morgen,
wo (an welcher Stelle) bindet man php (1) code am besten in einer Seite (2) ein? Ein echo z.B. natürlich da wo man es braucht, aber allgemeine Sachen wie z.B: ein DB Abfrage?
(1)
<?php
include 'include/odbc_connect.php';
$select_sql = "SELECT * FROM Test";
$result = odbc_exec($db, $select_sql);
$i = 0;
while (odbc_fetch_row($result) ) {
$Nummer[$i] = odbc_result($result, "Nummer");
$i++;
}
?>
(2)
<!DOCTYPE...>
<html>
<head>
</head>
<body>
</body>
</html>
Jürgen
-
Hi!
wo (an welcher Stelle) bindet man php (1) code am besten in einer Seite (2) ein?
Es gibt kein "am besten". Es gibt einige Vorgehensweisen, die man bei passender Gelegenheit anwenden kann. Eines wäre das EVA-Prinzip - Trennung nach Eingabe, Verarbeitung und Ausgabe, also zuerst die Eingabedaten gegebenenfalls behandeln, dass die eigentliche Datenverarbeitung vornehmen und dabei die auszugebenden Werte geeignet sammeln. Erst zum Schluss erfolgt dann die Ausgabe der ermittelten Daten an passender Stelle in das Seiten-Gerüst.
Lo!
-
... EVA-Prinzip ...
Klar, klingt logisch. Aber trotzdem bleibt für mich die Frage ob ich die (wie im Beispiel) ODBCverbindung vor DOCTYPE, zwischen DOCTYPE und head, in den head, zwischen head und body, in den body, hinter den body, oder hinter html schreibe(n sollte)?
Jürgen
-
h1,
Klar, klingt logisch. Aber trotzdem bleibt für mich die Frage ob ich die (wie im Beispiel) ODBCverbindung vor DOCTYPE, zwischen DOCTYPE und head, in den head, zwischen head und body, in den body, hinter den body, oder hinter html schreibe(n sollte)?
Ich empfehle, die DB-Anbindung so früh wie möglich zu machen noch vor der ersten (HTML)Ausgabe. Weil: Im Fall einer Nichtverfügbarkeit der DB-Anbindung macht das die Umleitung auf eine Fehlerseite einfacher.
Warum eine Fehlerseite? Nun, die Betonung lege ich auf _eine_.
Was im EVA-Prinzip nicht so gut beim Besucher ankommen würde, wäre eine Meldung, dass die DB-Anbindung nicht funktioniert, nachdem Punkt "E" bereits erfolgt ist.
Hotti
--
Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein.-
Hi!
Ich empfehle, die DB-Anbindung so früh wie möglich zu machen noch vor der ersten (HTML)Ausgabe.
So früh wie möglich ist eigentlich nicht sinnvoll. Erst einmal die Eingabedaten prüfen. Wenn die für eine Weiterverarbeitung nicht geeignet sind, kann man sich das DB-Handling ganz sparen.
Weil: Im Fall einer Nichtverfügbarkeit der DB-Anbindung macht das die Umleitung auf eine Fehlerseite einfacher.
Warum eine Fehlerseite? Nun, die Betonung lege ich auf _eine_.Warum eine extra Seite? Das sieht aus HTTP-Sicht unsinnig aus. Statt dem erwarteten Ergebnis bekommt der Client ein 302 und anschließend ein 200. Ein 404 statt 200 wäre noch seltsamer.
Was im EVA-Prinzip nicht so gut beim Besucher ankommen würde, wäre eine Meldung, dass die DB-Anbindung nicht funktioniert, nachdem Punkt "E" bereits erfolgt ist.
Deswegen gibt man ja nicht sofort und möglichst noch mit die() die Meldung aus, sondern sammelt sie an geeigneter Stelle (eine Variable $error oder auch ein Array für mehrere Meldungen), überspringt wenn es sinnvoll ist den Gut-Fall-Verarbeitungspfad und geht zum A-Teil über. Der A-Teil weiß nur anhand des vorhandenen Inhalts von $error, ob im BODY oder Content-DIV oder wo auch immer statt des eigentlichen Ergebnisses die Fehlermeldung(en) auszugeben ist/sind.
Lo!
-
h1,
Warum eine extra Seite?
Ganz einfach: Für meine Scripts mit DB-Anbindung (wovon es mehrere gibt) muss ich die nur einmal erstellen.
Das sieht aus HTTP-Sicht unsinnig aus. Statt dem erwarteten Ergebnis bekommt der Client ein 302 und anschließend ein 200. Ein 404 statt 200 wäre noch seltsamer.
Natürlich gibt es auch bei meinen Scripts eine Fehlerseite, die gleich mit Status 200 kommt. Die ist dann sogar so beschaffen, dass die im gleichen Ordner erscheint, wie die Anwendung, die den Fehler erzeugt.
Was im EVA-Prinzip nicht so gut beim Besucher ankommen würde, wäre eine Meldung, dass die DB-Anbindung nicht funktioniert, nachdem Punkt "E" bereits erfolgt ist.
Deswegen gibt man ja nicht sofort und möglichst noch mit die() die Meldung aus, sondern sammelt sie an geeigneter Stelle (eine Variable $error oder auch ein Array für mehrere Meldungen), überspringt wenn es sinnvoll ist den Gut-Fall-Verarbeitungspfad und geht zum A-Teil über. Der A-Teil weiß nur anhand des vorhandenen Inhalts von $error, ob im BODY oder Content-DIV oder wo auch immer statt des eigentlichen Ergebnisses die Fehlermeldung(en) auszugeben ist/sind.
Ja, Freilich. Wenn zwischen dem ersten Zeigen eines Eingabeformulars und der Verarbeitung der DB-Server abraucht, hat der Besucher Pech gehabt. Aber auch dieser Fall ist erfasst, wenn die DB-Verfügbarkeit gleich am Anfang der Anwendung geprüft wird, denn die wird ja beim Submit neu gestartet.
(FastCGI mit permanenter DB-Anbindung mal ausgenommen)
Hotti
--
Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein.-
Hi!
Warum eine extra Seite?
Ganz einfach: Für meine Scripts mit DB-Anbindung (wovon es mehrere gibt) muss ich die nur einmal erstellen.Du solltest dich mit Dateioperationen beschäftigen, denn damit kann man den Inhalt einer anderen Datei im laufenden Script einlesen und als Antwort an den Webserver übergeben, ohne dass man den Client eine Zusatzrunde drehen lassen muss und dem Webserver einen weiteren Request abarbeiten lässt.
Wenn zwischen dem ersten Zeigen eines Eingabeformulars und der Verarbeitung der DB-Server abraucht, hat der Besucher Pech gehabt. Aber auch dieser Fall ist erfasst, wenn die DB-Verfügbarkeit gleich am Anfang der Anwendung geprüft wird, denn die wird ja beim Submit neu gestartet.
Was setzt du dann dem Besucher vor: "Tut mir leid, ich bin nicht in der Lage ein DBMS verfügbar zu halten oder für eine alternative Verarbeitung der Anfrage zu sorgen. Geh bitte bei der Konkurrenz einkaufen."? Ein Abbrechen wegen DBMS-Unpässlichkeit sollte ein zu vermeidendes Verhalten. Wenn man also eine alternative Verarbeitung aufsetzt, und sei es auch nur, sich eine E-Mail zuschicken zu lassen, muss man die Daten ebenfalls auf Plausibilität prüfen. Ich sehe immer noch keinen wirklichen Grund, eine Verbindung frühestmöglich statt frühestnötig aufzubauen.
Lo!
-
Hello,
Was setzt du dann dem Besucher vor: "Tut mir leid, ich bin nicht in der Lage ein DBMS verfügbar zu halten oder für eine alternative Verarbeitung der Anfrage zu sorgen. Geh bitte bei der Konkurrenz einkaufen."? Ein Abbrechen wegen DBMS-Unpässlichkeit sollte ein zu vermeidendes Verhalten. Wenn man also eine alternative Verarbeitung aufsetzt, und sei es auch nur, sich eine E-Mail zuschicken zu lassen, muss man die Daten ebenfalls auf Plausibilität prüfen. Ich sehe immer noch keinen wirklichen Grund, eine Verbindung frühestmöglich statt frühestnötig aufzubauen.
Wäre nicht "spätestmöglich" statt "frühestnötig" besser hier?
Du bist doch sonst immer ein Verfechter vom Lazy-Connect.Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hi!
Wäre nicht "spätestmöglich" statt "frühestnötig" besser hier?
Du bist doch sonst immer ein Verfechter vom Lazy-Connect."spätestmöglich" == "frühestnötig", so meinte ich das. Ich würde mich nicht als Verfechter von irgendwas sehen, für das es Alternativen gibt. Zur Beachtung des Kontextwechsels sehe ich die nicht. Aber Lazy-Connect ist etwas, das man machen kann, aber nicht machen muss. Soweit ich mich erinnere, war es nur bei den Postings, die bei dir möglicherweise den Verfechter-Eindruck hinterlassen haben, so, dass zwar mein Vorschlag zum Lazy-Connect angenommen wurde, er jedoch verbesserungswürdig implementiert wurde, so dass ich da nachhaken musste. Wenn man schon etwas implementiert und es es in einem konkreten Fall keinen plausiblen Grund gibt davon abzuweichen, kann man das auch richtig tun.
Lo!
-
-
-
-
-
Hello,
Ich empfehle, die DB-Anbindung so früh wie möglich zu machen noch vor der ersten (HTML)Ausgabe. Weil: Im Fall einer Nichtverfügbarkeit der DB-Anbindung macht das die Umleitung auf eine Fehlerseite einfacher.
Was im EVA-Prinzip nicht so gut beim Besucher ankommen würde, wäre eine Meldung, dass die DB-Anbindung nicht funktioniert, nachdem Punkt "E" bereits erfolgt ist.
E (oder I) ist eindeutig dem Controller zuzuordnen. Der Controller ist zuständig für die Entgegennahme des Requests. Ohne Request keine weiteren Handlungen.
Datenbankverbinduung ist ausschließlich Bestandteil des Models und dieses gehört gleichzeitig zu Processing (Verarbeitung), ist aber dem Controller unterzuordnen. Nur der Controller korrespondiert mit dem Model.
Wenn man nun also IPO und MVC beachten möchte, kann man die DB-Verbindung erst herstellen lassen, wenn alle Daten (von außen) zur Verfügung stehen.
Das Veranlassen einer Fehlerseite ist ebenfalls Aufgabe des Controllers. Die eigentlich Ausgabe wäre dann Aufgabe von Output (Ausgabe) und damit auch von View.
Mir bleibt als letzte Frage zum Schluss nur, ob man View und Output so einfach gleichsetzen darf, oder ob der View auch eigene Prozessschritte enthalten darf, die jedoch nicht mehr zum eigentlichen Processing des Controllers gehören?
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hi!
Mir bleibt als letzte Frage zum Schluss nur, ob man View und Output so einfach gleichsetzen darf, oder ob der View auch eigene Prozessschritte enthalten darf, die jedoch nicht mehr zum eigentlichen Processing des Controllers gehören?
Es gibt kein Gesetz, dass vorschreibt, wie etwas zu implementieren ist. Wenn man vom MVC-Model aus gutem Grund in einigen Punkten abweicht, so kann man das ohne weiteres tun. Diese Patterns sind noch nicht mal eine Empfehlung sondern nur eine Beschreibung eines Lösungsmusters, das sich aufgrund von Erfahrungen herausgebildet hat. Man kann diese Erfahrung nutzen, muss das aber nicht (exakt so) tun. Es ist immer alles irgendwie Prozessschritt. Wenn ein Wert zur Darstellung von Integer in String umgewandelt wird, ist das doch auch ein Prozess, der aber in der View angesiedelt ist. Ebenso ist es nicht undenkbar, dass die View zur Erledigung ihrer Aufgabe einen Datenbankzugriff ausführt, um beispielsweise an ein Template zu gelangen.
Lo!
-
-
-
Hallo,
... EVA-Prinzip ...
Aber trotzdem bleibt für mich die Frage ob ich die (wie im Beispiel) ODBCverbindung vor DOCTYPE, zwischen DOCTYPE und head, in den head, zwischen head und body, in den body, hinter den body, oder hinter html schreibe(n sollte)?die Überlegung ist eigentlich irrelevant. Denn der PHP-Parser kümmert sich nicht um HTML, reicht es einfach nur durch, und der Browser (HTML-Parser) sieht kein PHP mehr. Es ist daher nicht sinnvoll, zwischen beiden eine Korrelation herzustellen, wie du es gerade versuchst.
Entscheidend sollte eigentlich nur eine saubere Strukturierung des Quellcodes sein; das ist es ja, was dedlfix mit EVA als gutem Beispiel auch schon empfohlen hat. Da im HTML versprenkelt Ausgaben stehen, deren Wert durch PHP erst ermittelt wird, ist es keine schlechte Idee, den PHP-Code ganz an den Anfang zu setzen. Man *muss* das sogar tun, wenn man noch individuelle HTTP-Header senden will (Content-Type, Status, Location).
So long,
Martin--
Zwischen Leber und Milz
passt immer noch'n Pils.
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
-
-
Mahlzeit dedlfix,
wo (an welcher Stelle) bindet man php (1) code am besten in einer Seite (2) ein?
Es gibt kein "am besten".
IMHO schon - und zwar das von Dir genannte EVA-Prinzip ... und zwar aus verschiedenen Gründen:
1.) Übersichtlichkeit: Klar strukturierter Code, der einem festen und logischen Schema folgt, ist IMHO deutlich einfacher verständlich - insbesondere wenn man nach Monaten mal wieder in eine Datei hineinschaut.
2.) Sicherheit: Wenn man *ALLE* erwarteten Eingabeparameter zu Anfang überprüft, ggf. vorbehandelt und die Werte in entsprechende Variablen packt, sollte man vor Überraschungen einigermaßen sicher sein (Merke: "ALL INPUT IS EVIL!").
3.) Flexibilität: Umleitungen sind (wieder) problemlos möglich - das unsägliche "Warning: Cannot modify header information - headers already sent [...]" tritt nicht mehr auf, wenn man die Eingabeüberprüfung und Datenverarbeitung durchführt, bevor man anfängt, irgendetwas an den Browser auszugeben.
MfG,
EKKi--
sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|-
Hi!
wo (an welcher Stelle) bindet man php (1) code am besten in einer Seite (2) ein?
Es gibt kein "am besten".
IMHO schon - und zwar das von Dir genannte EVA-Prinzip ... und zwar aus verschiedenen Gründen:Nun, ich dachte auch an andere Strukturierungsverfahren, wie beispielsweise dem MVC-Pattern. Aber im Grunde genommen hält sich das auch nur im Wesentlichen an das EVA-Prinzip.
Lo!
-
Hello,
Nun, ich dachte auch an andere Strukturierungsverfahren, wie beispielsweise dem MVC-Pattern. Aber im Grunde genommen hält sich das auch nur im Wesentlichen an das EVA-Prinzip.
Ich würde meinen, es steht senkrecht darauf :-)
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hello,
IMHO schon - und zwar das von Dir genannte EVA-Prinzip ... und zwar aus verschiedenen Gründen:
Nun, ich dachte auch an andere Strukturierungsverfahren, wie beispielsweise dem MVC-Pattern. Aber im Grunde genommen hält sich das auch nur im Wesentlichen an das EVA-Prinzip.
IPO: Wie machen wir Kartoffelsalat?
http://www.cs.usyd.edu.au/~dyoo4334/Paul_Yoo/CMPE111_files/yoo-w3.pdf*grins*
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
-
2.) Sicherheit: Wenn man *ALLE* erwarteten Eingabeparameter zu Anfang überprüft, ggf. vorbehandelt und die Werte in entsprechende Variablen packt, sollte man vor Überraschungen einigermaßen sicher sein (Merke: "ALL INPUT IS EVIL!").
Naja Eva stottert manchmal EVEVA
Zum Beispiel wenn die Validität einer Eingabe abhängig ist von einem bereits EV-behandelten anderen Parameter.
Typischer Fall sind Plugins.
kann sich also so abspielen EV->EVA->VA
Manche misstrauen sogar eigenen Modulen
EV
(->EVA->)E
V:stack->A
(->EVA->)E
V:stack->A
ADas kann dann, wenn es umfangreich wird, zu einer Performancekrücke werden.
mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische-
Hi!
Naja Eva stottert manchmal EVEVA
Zum Beispiel wenn die Validität einer Eingabe abhängig ist von einem bereits EV-behandelten anderen Parameter.Dafür kann aber das EVA-Prinzip nichts, sondern nur diejeinigen, die sich nicht daran halten. Etwas das munter und froh die Verarbeitungsschritte mischt, kann nicht mehr als "gemäß EVA-Prinzip erstellt" bezeichnet werden.
Lo!
-
Hi!
Naja Eva stottert manchmal EVEVA
Zum Beispiel wenn die Validität einer Eingabe abhängig ist von einem bereits EV-behandelten anderen Parameter.Dafür kann aber das EVA-Prinzip nichts, sondern nur diejeinigen, die sich nicht daran halten. Etwas das munter und froh die Verarbeitungsschritte mischt, kann nicht mehr als "gemäß EVA-Prinzip erstellt" bezeichnet werden.
Kommt darauf an, was du unter E verstehst.
Soll E umfassend sein, kann EVA nicht einmal eine Username-PW-Combo validieren weil die Validität des PWs bereits von der Anwendung des Usernamens abhängig ist.Du kannst natürlich sagen: V sei nicht involviert, weil nichts geschrieben wird.
Das ist aber falsch, denn die Rückmeldung führt zu einem Schreibprozess, und sei es nur in eine variable für die spätere Ausgabe, statt in eine Datenbank.mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische-
Hi!
Kommt darauf an, was du unter E verstehst.
V ist alles was Geschäftslogik beinhaltet. Dazu zählt auch die Plausibilitätsprüfung gemäß deren Anforderungen. E ist mehr oder weniger nur die Entgegennahme der Daten, beispielsweise das Befreien aus der Transportsicherung und die Umwandlung in einen passenderen Datentyp wenn notwendig.
Soll E umfassend sein, kann EVA nicht einmal eine Username-PW-Combo validieren weil die Validität des PWs bereits von der Anwendung des Usernamens abhängig ist.
Das ist eine Aufgabe für V.
Du kannst natürlich sagen: V sei nicht involviert, weil nichts geschrieben wird.
V heißt nicht nur Daten wegzuschreiben. Auch das Abfragen von Daten gemäß der Werte der übergebenen Parameter zählt dazu.
Das ist aber falsch, denn die Rückmeldung führt zu einem Schreibprozess, und sei es nur in eine variable für die spätere Ausgabe, statt in eine Datenbank.
Auch das Anlegen einer neuen Variable wäre demnach ein Schreibprozess, und das tritt auch im E-Teil auf. Alles Datenlesen dem E und Datenschreiben dem V zuzuordnen ist unsinnig. Und auch der Ausgabeteil darf Variablen lesen und anlegen, wenn er das für die Erledigung seiner Aufgebe benötigt.
Lo!
-
-
-
-
-