HTML / php

[wodim]

du weisst, dass html keine programmiersprache ist, sondern nur zum text auszeichnen und struktrieren da ist? html ist folglich weder objektorientiert, noch gibt es da schleifen und verzweigungen
genau das gleiche mit css...

Ok, das Ganze läuft dann wohl darauf hinaus:

Mein "Hauptprogramm" muss ich in PHP schreiben, die Vorlagen sind HTML, die Formate CSS - da werde ich wohl nicht drumrumkommen?

Aber sag bitte nicht, temporäre Dateien sind unverzichtbar - schon gar für solche "Standards" wie:

- "User Anton hat sich eingeloggt, stelle für ihn die Verbindung zur Datenbank her"

- "Hier kam gerade eine Anfrage von User Berta - hier hast du das SQL-Statement dazu. Führe diese Datenbankabfrage aus und liefere die Daten an die Seite, die Berta in ihrem Browser sieht."

[piero]

Ok, das Ganze läuft dann wohl darauf hinaus:

Mein "Hauptprogramm" muss ich in PHP schreiben, die Vorlagen sind HTML, die Formate CSS - da werde ich wohl nicht drumrumkommen?

richtig erkannt

Aber sag bitte nicht, temporäre Dateien sind unverzichtbar - schon gar für solche "Standards" wie:

- "User Anton hat sich eingeloggt, stelle für ihn die Verbindung zur Datenbank her"

- "Hier kam gerade eine Anfrage von User Berta - hier hast du das SQL-Statement dazu. Führe diese Datenbankabfrage aus und liefere die Daten an die Seite, die Berta in ihrem Browser sieht."

hast du dir eine dieser cache seiten überhaupt schonmal angeschaut?^^[/quote][/code]

[wodim]

hast du dir eine dieser cache seiten überhaupt schonmal angeschaut?^^

Nö, nur massenweise solche Dateinamen gesehen wie "sql_[ellenlange Hezadezimalzahl].php"

Da ist mir die Lust zum Anschauen erst mal vergangen - sollte ich vielleicht doch - würde ich dann sogar darin einen Sinn erkennen?

[piero]

möglicherweise schon^^

[wodim]

Meinste. Na, denn schaunmerdochmal. Also ganz laienhaft interpretiere ich mir das so: Das Forum speichert jeden Datenbankzugriff als so eine Datei. Und wenn's mal wieder auf die Datenbank zugreifen soll (was im Moment bei mir noch eher selten vorkommt, aber irgendwann wird ja auch mal ein bisschen Betrieb drin sein) - grast es erst mal den Cache durch: Gab's die Abfrage schonmal? Ach ja - gugge, hier hatten wir doch sowas schonmal:

Code: Alles auswählen

<?php

/* SELECT m.*, u.user_colour, g.group_colour, g.group_type FROM (moderator_cache m) LEFT JOIN users u ON (m.user_id = u.user_id) LEFT JOIN groups g ON (m.group_id = g.group_id) WHERE m.display_on_index = 1 AND m.forum_id = 17 */

$expired = (time() > 1228678365) ? true : false;
if ($expired) { return; }

$this->sql_rowset[$query_id] = unserialize('a:0:{}');

?>

Aber nein - die ist zu alt! $expired = (time() > 1228678365) ist "true" - also "Verfallsdatum überschritten"! Nix wie 'raus hier, und neue Abfrage erstellen. Damit natürlich den Cache weiter zumüllen, ohne die alte zu löschen. Dafür ist schließlich mein Administrator zuständig.

[piero]

hmm... die datei solle eogentlich wieder gelöscht werden... sonst hätte ich in meinem cache tausende sql dateien^^

und wie das allgemein mit dem cache so funktioniert, weiss ich nicht so genau

[wodim]

Also ich stelle mir das ein bisschen anders vor - aber was heißt hier vorstellen - so wird's ja wohl seit Jahrzehnten millionenfach praktiziert, wo User einer relationalen Datenbank vor ihrer grafischen Oberfläche (GUI) sitzen. Z.B. in meiner letzten Firma, wo ich für die sowas programmiert habe (allerdings in Smalltalk, das ist Objektorientierung in Vollendung). Die sog. "Three-Tier"- Architektur - drei Schichten:

(1.) "Ganz oben" das GUI, (3.) "ganz unten" die Datenbank. Dazwischen (2.) die "Objektschicht" (in Smalltalk sagt man dazu echt "Objektsuppe" ).

Beispiel: User Anton will die Daten von Kundin Berta sehen. Dazu tippt er Bertas Kundennummer ein. Das Programm guckt nun: Gibt's schon eine Instanz der Klasse "Kunde", bei der die Eigenschaft "Kundennummer" den Wert "Bertas Nummer" hat?

Ja? Dann nix wie her mit den Werten für die anderen Eigenschaften - und die gehen an das GUI von User Anton. Fertig. Da brauchen wir die Datenbank gar nicht.

Nein? Dann müssen wir doch die Datenbank bemühen. Dafür basteln wir uns den SQL-String zusammen - und ab damit an die Datenbank. Die Daten kommen postwendend - rüber damit zum GUI von User Anton!

Fertig. Und da soll's Leute geben, die das speichern, und zwar jeden Datenbankzugriff als Textdatei? Wozu soll'n das gut sein? Der einzige Unterschied: Hier ist das "Übertragungsmedium" zwischen den Schichten (1.) und (2.) halt nicht ein lokales Netz, sondern das Internet.

[piero]

Beispiel: User Anton will die Daten von Kundin Berta sehen. Dazu tippt er Bertas Kundennummer ein. Das Programm guckt nun: Gibt's schon eine Instanz der Klasse "Kunde", bei der die Eigenschaft "Kundennummer" den Wert "Bertas Nummer" hat?

Ja? Dann nix wie her mit den Werten für die anderen Eigenschaften - und die gehen an das GUI von User Anton. Fertig. Da brauchen wir die Datenbank gar nicht.

das musst du mir genauer erklären... kenne smalltalk nur vom namen her^^

wo ist diese instanz? im programm selber in einer variable?
läuft das programm 24/7 und wird nicht ständig beendet und wieder gestartet?

[wodim]

das musst du mir genauer erklären... kenne smalltalk nur vom namen her^^

Das Prinzip ist bei allen objektorientierten Sprachen dasselbe. Das geht bei C++ los - und die höheren Sprachen (also mit denen man ohne größeren Aufwand schöne grafische Oberflächen erstellen kann und die auch Datenbankanbindung via SQL haben), mit denen ich gearbeitet habe, waren: Access Basic, Visual Basic, Centura (das nennt sich auch direkt "SQL-Windows") und Smalltalk.

Und weil ich da in in HTML überall was von

Code: Alles auswählen

class="siehe laberlaber.css"

lese, dachte ich ja, das wäre da genauso - war aber wohl ein typischer Fall von "Denkste"?

wo ist diese instanz? im programm selber in einer variable?

Das Objekt definierst du im Programm. Also jetzt schematisch (sprachenunabhängig ):

Objekt "Kunde" - Eigenschaften:

- Kundennummer
- Name
- Adresse
- Telefon
- Konto
-
-
-

Für jede dieser Eigenschaften schreibst du zwei Prozeduren (dafür erzeugt z.B. der VB-Editor schon Codegerippe): Eine Put(), die setzt die Eigenschaft auf einen Wert, den du ihr übergibst, und eine Get(), die den Wert ausliest und zurückliefert. Im Programm sieht das dann so aus - meinetwegen:

Kunde.Kundennr(4711).Put_Name("Berta") setzt die Eigenschaft "Name" einer Instanz des Objekts "Kunde" auf "Berta" (der Instanz, deren Eigenschaft "Kundennr" den Wert "4711" hat).

Das Objekt "Kunde" hast du also im Programmcode definiert, zur Laufzeit werden so viele Instanzen erzeugt, wie gebraucht werden (und deren Daten aus der Datenbank ausgelesen). Die stehen dann im Arbeitsspeicher. Also sagen wir: Wenn 200 Mitarbeiter im Netz sind, und jeder braucht die Daten von 10 Kunden gleichzeitig, macht das 2000 Instanzen des Objekts "Kunde" (wenn allerdings alle 200 sich mit ein und demselben Kunden beschäftigen, brauchen wir nur eine Instanz).

Jedes Objekt braucht natürlich z.B. auch eine Methode "Speichern" - Beispiel Objekt "Kunde":

Speichern (kundennr, name, adresse, telefon, konto)

Die bastelt dann den SQL-String mit den Werten zusammen, die ihr übergeben werden, und führt in aus:

Code: Alles auswählen

ExecuteSQL ("UPDATE kunde SET name =" & name & ", adresse =" & adresse & ", telefon = " & telefon & ", konto = " & konto & " WHERE kundennr = " & CStr(kundennr))

Bei etwas komplexeren Aktionen möchte man natürlich nach dem Transaktionsprinzip arbeiten, also eine Datenbanktransaktion wird entweder komplett ausgeführt oder gar nicht - (commit, wenn's geklappt hat, oder rollback, wenn was schiefgelaufen ist ).

läuft das programm 24/7 und wird nicht ständig beendet und wieder gestartet?

Muss es ja wohl. Zumindest während der Arbeitszeit der User.

Smalltalk ist ja da so komfortabel: Du kannst ein "Image" machen, das ist quasi der aktuelle Stand der "Objektsuppe" "eingefroren". Also bevor du den Server 'runterfährst oder aus sonst irgendeinem Grund das Programm mal beenden musst - meinetwegen, um eine neue Version zu starten, mit deinen Änderungen. (Ob es auch einen Absturz vorausahnt und schnell noch ein Image macht, da bin ich etwas überfragt. )

Nachtrag:

hmm... die datei solle eogentlich wieder gelöscht werden... sonst hätte ich in meinem cache tausende sql dateien^^

Stimmt, hab' ich mir jetzt auch überlegt: Das ist wohl etwa so wie bei der Objektgeschichte mit der "Lebensdauer" der Instanzen im Speicher. Die müssen auch irgendwann gekillt werden, wenn sie einige Zeit nicht gebraucht werden, sonst werden es ja immer mehr. Wie das genau organisiert ist, weiß ich aus dem Hut jetzt nicht mehr, darum brauchte ich mich ja auch nie zu kümmern.

[piero]

Das Objekt definierst du im Programm. Also jetzt schematisch (sprachenunabhängig ):

ja das ist mir klar^^ (gibts in php auch )
aber wo ist die instanz?^^
als variable im programm, oder?^^

Das Objekt "Kunde" hast du also im Programmcode definiert, zur Laufzeit werden so viele Instanzen erzeugt, ....

hast du dir schonmal die laufzeit eines phpsckriptes angeschaut?
-> benutzer ruft script auf
-> inhalt im script wird abgearbeitet
-> wenn alles abgearbeitet ist, ist skriptlaufzeit beendet.
-> sämtliche variablen vom skript sind weg.

und um halt einige daten von oft benötigten instanzen werden dann im cache als datei abgespeichert...


achja, html hat nix mit php zu tun und php hat nur was mit html zu tun, wenn über php htmlcode ausgegeben werden soll^^