Muss auf jeder php Seite "mysql_connect" darauf stehen?

[Nadine5]

Halllo,

muss auf jeder php Seite "mysql_connect" darauf stehen?
Oder was schreibt man auf die 2 oder 3 Seite usw. drauf, wenn man auf allen Seiten den Datenbank zugriff benötigt?

Kann eine php Seite glechzeitig eine Eingabe Seite und eine Ausgabe Seite sein?
Oder muss eine Seite entweder eine Eingabe Seite oder eine Ausgabeseite sein?


<?php
$verbindung = mysql_connect ("Servername",
"Username", "Passwort")

[Altrea]

Hallo Nadine,

muss auf jeder php Seite "mysql_connect" darauf stehen?

Jein. Es ist nicht entscheidend, in welcher Datei der Datenbankconnect definiert ist, sondern ob er an der Codestelle wo er gebraucht wird existiert.
Es gibt verschiedene Möglichkeiten und Architekturen die es ermöglichen, einen Datenbankconnect oder die Logik zum Aufbauen eines solchen in eine andere PHP-Datei zu "übergeben". Die einfachste dieser Möglichkeiten ist ein Include.

Kann eine php Seite glechzeitig eine Eingabe Seite und eine Ausgabe Seite sein?
Oder muss eine Seite entweder eine Eingabe Seite oder eine Ausgabeseite sein?

Eine PHP-Seite ist weder eine Eingabeseite noch eine Ausgabeseite.
Eine von einem PHP-fähigen Webserver verarbeitete PHP Seite kann hingegen sowohl das eine als auch das andere sein, oder gar beides.
Ein Stichwort hierzu wäre das sogenannte Affenformular, welches sowohl die Eingabe entgegennimmt als auch bereits getätigte Eingaben wieder ausgibt.

mit freundlichen Grüßen,
Altrea

[Nobbie]

Um das noch ein wenig auszuführen:

PHP ist eine Programmiersprache, die darauf konzipiert ist, HTML Seiten "dynamisch" (= veränderbar zur Laufzeit) zu gestalten. Generell geschieht die Eingabe von Benutzerdaten mit einem sog. Formular, das ist ein spezielles Konstrukt in HTML.

Die Ausgabe ist an keinerlei spezielle Konstrukte geknüpft, da kann man auch Formulare benutzen, aber meistens wird ganz normales HTML benutzt.

Sowohl bei der Eingabe wie bei der Ausgabe gibt es ein Problem, was alleine mit HTML nicht lösbar ist:

a) wie bekommt man die vom Anwendern im Browser eingetippten Werte in eine Datenbank? Das kann HTML nicht. Und dafür gibt es im FORM-Element das TAG "action=....." und dort muss ein sog. "CGI-Script" angegeben werden, das ist im Prinzip einfach ein ausführbares Programm (beispielsweise in PHP geschrieben oder auch in Perl, oder auch C oder was auch immer) und das wird vom Apache-Server, der die im Formular eingetippten Daten über die Leitung zugestellt bekommt, aufgerufen und es werden diese Daten auf bestimmte Art und Weise (und das entspricht dann der sog. "CGI" Konvention) an dieser Programm übergeben und dieses Programm trägt seinerseits diese Daten in die Datenbank ein.

b) wie bekommt man die Daten aus der Datenbank zur Anzeige in ein HTML Dokument? Denn der Browser versteht kein PHP, der kann im Prinzip nur HTML (und JavaScript, aber das lassen wir mal außen vor). HTML Dateien kann man aber nicht einfach so verändern, wenn Du eine HTML Datei entwirfst, dann ist eine statische Datei, da steht irgendetwas drin, aber das kann nicht geändert werden (nicht von Apache). Und da bedient man sich wieder der Sprache PHP (auch hier würde es wieder ein Perl oder C Programm genauso tun), dieses Programm holt die gewünschten Daten aus der Datenbank, bereitet die so auf, dass das am Ende ein vollständiges HTML Dokument steht und das wird vom Server (Apache) an den Browser geschickt.

Um den ganzen Mechanismus überhaupt nachvollziehen zu können, muss man unbedingt die grundsätzliche Arbeitsweise kennen, wie HTTP funktioniert. Im Prinzip funktioniert die Kommunikation zwischen einem Client (also ein Browser) und einem Webserver (beispielsweise Apache) auf die folgende Art (die ungewohnt ist, wenn man nur auf dem PC arbeitet, da funktioniert die Kommunikation zwischen den Programmen vollkommen anders):

Ein Browser bekommt vom Anwender den Auftrag, von einem bestimmten Server eine bestimmte Datei zu holen. Das kann ein Video sein, ein Foto, oder eben (der häufigste Fall) eine Textdatei im HTML Format. HTML Dateien sind ganz normale Textdateien, aber diese Texte sind auf bestimmte Weise formatiert. Sicher hast Du schon HTML Dateien im Quellcode gesehen. Diesen Auftrag erhält der Browser entweder dadurch, dass man oben die Adresszeile das gewünschte Dokument "formuliert", die Syntax die dabei benutzt wird nennt sich "URL". Das ist das berühmte http://..... und so weiter. Die andere Variante besteht darin, dass man in einem schon geladenen HTML Dokument einen Link anklickt, oder ein Formular abschickt.

So oder so analysiert der Browser erst einmal ganz genau, was er eigentlich tun soll und macht sich dann an die Arbeit. Dazu gehört u.a., dass er erst einmal den Server finden und kontaktieren muss, wo das gewünschte Dokument liegt. Dazu muss er meistens aus diesem sog. "Domainname" eine IP machen, besser gesagt. er muss herausfinden, mit welcher IP dieser Domainname verbunden ist. Dazu gibt es spezielle Mechanismen, die ihrerseits auf auf Server basieren, das ganze läuft unter Oberbezeichnung "DNS", das ist die Abkürzung für "Domain Name System". Das soll uns hier egal sein, wie das funktioniert, am Ende des Vorgangs kennt der Browser diese IP und er schickt an diese IP eine Anfrage, einen sog. "Request" (das ist nur das englische Wort für "Anfrage"). Wenn es gut, dann gibt es tatsächlich einen Server mit dieser IP und da "lauscht" (in English "LISTEN") ein Apache Server, ob jemand an der Haustür klingelt (das kann man sich ungefähr so vorstellen). Dann gibt Apache zu erkennen, dass er bereit ist, etwas zu tun, dann tauschen der Browser und Apache ein paar Daten miteinander aus, im Grunde sprechen sie kurz miteinander und verfahren nach einem fest vorgeschriebenen "Protokoll" (genau wie im wirklichen Leben bei offziellen Anlässen) um sich bekannt zu machen und der Browser teilt dem Apache mit, was er gerne von ihm hätte. Diese Protokoll zwischen diesen beiden heißt "HTTP" (Hypertext Transfer Protokoll).

Nun geht Apache auf die Suche, der Browser wartet so lange (und das ist die Wartezeit, die Du vom Browser angezeigt bekommst, evtl mit Eieruhr oder wie auch immer), bis Apache quasi wieder zurückkommt und das gewünschte Dokument ausliefert. Dabei hat der Browser keine Möglichkeit festzustellen, wie Apache an das Dokument gekommen ist, wo das eigentlich herkommt, bleiben wir bei der Vorstellung mit der Haustür, der Apache kommt zurück an die Türe und händigt das Dokument aus. Das kann er auf Lager gehabt haben (im Falle einer HTML Datei), das kann er aber auch in höchster Eile schnell zusammengebaut haben, das wäre dann der Fall, wenn das Dokument Daten enthält, die aus einer Datenbank kommen. Denn Apache kann nicht einfach die Datenbank ausliefern, das geht natürlich gar nicht, Apache kann nur veranlassen (meistens durch ein PHP Script), dass das Dokument schnell zusammengebaut wird.

Dann nimmt der Browser das Dokument an, analysiert so ein wenig den Inhalt und zeigt diesen Inhalt dem Anwender so an, wie es eben in diesem HTML Dokumenten festgelegt ist.

Apache aber schließt in der Zwischenzeit die Türe, Browser und Apache trennen die Verbindung, Apache setzt sich wieder hin und lauscht, bis der nächste klingelt und der Browser langweilt sich auch, er zeigt jetzt nur noch die ganze Zeit das Dokument an. So lange, bis der Anwender ein anderes Dokument sehen will.

Und jetzt überlege mal genau, was das eigentlich so bedeutet (das ist nämlich das allerwichtigste, dass man das versteht). Wenn der Anwender jetzt auf diesem Dokument, was er da sieht, irgendetwas anklickt oder so und vom Browser ein anderes Dokument haben möchte, dann geht das ganze Spiel von vorne los. Und es ist auch so, dass der Anwender mit seinem Browser nicht (wie es sich die meisten Laien vorstellen) irgendwie "auf" einem Server wartet. Der Browser ist mit gar keinem Server verbunden, bei jeder Aufforderung durch den Anwender muss der Browser ganz von vorne anfangen und erst mal schauen, von welchem Server muss ich denn dieses Dokument holen. Wenn das genau der gleiche Server ist, wie ein paar MInuten vorher, dann ist das für den Anwender klar logisch und ersichtlich, aber für Browser und Apache gar nicht. Die sind grundsätzlich beide doof, obwohl die sich gerade erst gesehen haben, machen die gleiche Prozeder wieder von vorne und erkennen sich auch nicht wieder.

Es gibt auch diesen Zustand des "eingelogged" sein gar nicht in Wirklichkeit, so wie es hier beispielsweise in diesem Forum den Anschein an. Während ich hier sitze und diese Zeilen schreibe, ist mein Computer oder mein Browser nicht "eingelogged" auf dem Apache Friend Forum. Das ist nur ein geschickt programmierter Ablauf von Dokumenten, was den Anwender glauben läßt, in HTTP (so heißt diese ganze Welt) gäbe es so etwas wie "eingelogged". Das gibt es in HTTP gar nicht.

In Wirklichkeit hat sich der Browser ja längst verabschiedet und kreuzt ein paar Minuten später wieder auf. Das stellt natürlich ein ziemliches Problem dar (aus Sicht der Programmierer), denn die müssen es immer schaffen, dass die richtigen Daten an den Server gesendet werden. Und um dieses Problem lösen zu können, hat man einen wichtigen Mechanismus in HTTP eingebaut, und das nennt sich "Cookie". Ein Cookie (ein Keks) ist im Prinzip ein kleines etwas, was ein paar Daten aufbewahrt. Dieses Cookie wird vom Browser verwaltet, ein Browser kann beliebig viele Cookies verwalten (in echt sind das meistens ganz kleine Dateien, die irgendwo auf Deinem Rechner herumfliegen) und dieses Cookie hat eine ganz tolle Fähigkeit: jeder Webserver (also Apache) kann, wenn er das will, in ein solches Cookie irgendeine beliebige Information hineinschreiben und der Browser bewahrt dieses Cookie auf. Und im Browser hat man einen Mechanismus eingebaut, wenn der wieder an der Tür von irgendeinem Apache klingelt, dann geht er eben mal seine Keksdose und sucht gezielt nach dem Cookie (das dürfen auch mehrere Cookies sein), welches dieser Server/Apache zur Aufbewahrung gegeben hat und bringt das mit. Und wenn die Türe geöffnet wird, dann überreicht der Browser (im Rahmen des definierten Protokolls HTTP) dieses Cookie (oder mehrere Cookies) an den Apache. Apache schaut sich dieses Cookie bzw. den Inhalt davon an und liest sich durch, was da eigentlich drin steht. Da er den Inhalt aber auch selbst verfasst hat, ist das die geniale Möglichkeit, dass Apache diesen Browser "wiedererkennt".

Das kann man sich vorstellen wie eine Art Ausweis. Apache verteilt quasi irgendwelche Ausweise oder so (der Fantasie sind keine Grenzen gesetzt) und wenn der Browser wiederkommt, dann schaut Apache, ob der einen Ausweis mitbringt (nämlich ein bestimmtes Cookie mit einem bestimmten Inhalt) und dann weiß Apache, ach ja, das ist der, der war schon einmal hier.

Diese Cookies werden aber typischerweise gar nicht von Apache selbst gefüllt (das kann Apache zwar auch), sondern in PHP gibt es die auch die Möglichkeit, diese Cookies zu backen und mit Inhalt zu füllen. Diese Cookies werden dann von Apache an den Browser übergeben, übrigens noch bevor Apache dann auch noch das Dokument ausliefert, nach dem grundsätzlich gefragt wird.

Ich will das an dieser Stelle erst einmal nicht noch weiter ausführen, Du musst mit diesem Wissen versuchen nachzuvollziehen, was eigentlich genau passiert, wenn eine "PHP Seite" aufgerufen wird. Oder eine andere PHP Seite. Das bedeutet zunächst einmal, dass der Browser nach diesem PHP Dokument fragt. Nun ist es aber so, dass der Browser natürlich NICHT einfach dieses PHP Dokument haben will (das wäre ja doof), sondern eigentlich will der Browser das haben, was dieses PHP Script so fabriziert.

Allerdingst ist es so, dass der Browser das überhaupt gar nicht weiß, der weiß gar nicht, dass er eigentlich nicht das PHP Script will, sondern ein HTML Dokument, was von diesem PHP Script zusammengebaut wird. Der Browser glaubt, das ist das gleiche. Das weiß der nicht. Das Wissen darüber, dass bei einem PHP Dokument nicht (wie sonst HTML Dokumenten) einfach dieses Dokument ausgeliefert wird, sondern stattdessen dieses PHP Script "ausgeführt" wird und das Resultat davon an den Browser überreicht wird, dieses Wissen liegt bei Apache und in der Konfiguration von Apache. Apache wird so eingestellt, dass man ihm klar macht, wenn ein Browser nach einem PHP Script fragt, dann liefere nicht einfach dieses Script aus, so wie Du es bei HTML Dateien machen würdest, sondern starte dieses PHP Script, das wird eine Ausgabe zusammenbasteln und diese Ausgabe, die gibst Du zurück an den Browser.

Das war jetzt viel Theorie und wird möglichlerweise etwas sehr fordern, aber wenn Du diese Zusammenhänge begriffen und erkannt hast und auf Deine eigenen Scripts und HTML Dateien umsetzen kannst, dann beantworten sich Deine Fragen, beispielsweise die Frage mit dem mysql-connect, von alleine. Weil Du dann weißt, was genau wann passiert. Und dass es NICHT so ist, dass Browser und Server die ganze Zeit irgendwie verbunden sind.