Objektorientierung in PHP richtig anwenden bei einem Forum

[asdf (Robert)]

Hallo!

Ich hab beschlossen einen neuen Script zu schreiben. Dieser soll die objektorientierte Programmierung in PHP nutzten, da ich sehen will in wie Weit es einen Unterschied zu prozeduralem Programmieren macht. Das ganze will ich gleich bei einem Forum ausprobieren.
Nun wollte ich fragen wie Ihr bei einem Forum das

-Themenauflistung
-Threadauflistung
-Threadausgabe + Antwortenausgabe
-Regiestrier Möglichkeit
-Login
-Mehrere Themen
-Bearbeitung eigener Threads/Antworten
-verschiedene User mit verschiedenen Rechten

bieten sollte.

Ich selber habe mir gedacht, ich könnte eine Oberklasse erstellen die alles enthällt was alle sehen können (= unregistriert/registriert/Admin/...)

und dann jeweils unterklassen für Admin - ( Benutzer hohen Grades, Benutzer mittleren Grades - ... ) - Gast.

Wie würdet ihr hier das OOP ausnutzen?

Ehrlich gesagt kommt mir meine Variante als nicht zu sinvoll vor, ob das wahr ist würde sich herausstellen wenn ich das forum mal auf diese Weise mächte.

Sollte ich es überhaupt ausprobieren oder hat das überhaupt keien Sinn eurer Erfahrung nach.

mfG Robert

[Andreas-Lindig]

Hallo,

Nun wollte ich fragen wie Ihr bei einem Forum das
[...]
bieten sollte.

Ich finde Dein Deutsch schwer zu verfolgen. Etwas mehr Mühe hier ist vielleicht eine gute Vorübung für ein Forum.

-Themenauflistung

das klingt ja nach einer Boardansicht. Scheint schwer modern zu sein, würde ich trotzdem nicht machen. Oder willst Du gleich mehrere Foren in ein Programm packen?

-Threadauflistung
-Threadausgabe + Antwortenausgabe

hä? was ist denn der Unterschied zwischen "Threadauflistung
" und "Threadausgabe"?

-Bearbeitung eigener Threads/Antworten

Boy! Nachrichten im Nachhinein als nicht-Admin verändern?

Ich selber habe mir gedacht, ich könnte eine Oberklasse erstellen die alles enthällt was alle sehen können (= unregistriert/registriert/Admin/...)

und was wäre ein Objekt davon?

und dann jeweils unterklassen für Admin - ( Benutzer hohen Grades, Benutzer mittleren Grades - ... ) - Gast.

naja, ich würde nicht gleich übertreiben, aber vom Ansatz kann ich das schon eher nachvollziehen. Ich habe z.B. eine Klasse "userdaten" - in den Objekten dieser Klasse stehen persönliche Voreinstellungen und gelesene Postings des jeweiligen Users drin.

Wie würdet ihr hier das OOP ausnutzen?

Ich habe das ganze Forum zunächst vom User aus betrachtet. Da ist dann jeder Frame ein Objekt. In dem ListenFrame steckt das Objekt "Liste", darin steckt das Objekt "Block" (man kann meine Liste von Block zu Block blättern), darin stecken die Threads als Objekte und darin die Postings als Objekte. Bei der Anzeige eines Postings zeige ich eben dieses Objekt an. Dann habe ich auch ein Datenbankobjekt - das kann Postings holen, Postings löschen, Postings schreiben usw. Die Suche ist bei mir auch ein Objekt, das für den einzelnen Suchvorgang konstruiert wird und wo alle Infos stehen, was der User als Sucheingrenzung eingegeben hat und welche Zwischenergebnisse es gibt.

Ehrlich gesagt kommt mir meine Variante als nicht zu sinvoll vor

vor allem wenig durchdacht - so erscheinen mir Deine Formulierungen jedenfalls. Ich würde mir da mal einen Plan aufzeichnen.

Sollte ich es überhaupt ausprobieren oder hat das überhaupt keien Sinn eurer Erfahrung nach.

probier, was Du willst. Übung macht den Meister :)

Gruß, Andreas

[asdf (Robert)]

Hallo!

Etwas mehr Mühe hier ist vielleicht eine gute Vorübung für ein Forum.

Werde mit dieser Antwort gleich damit beginnen.

-Themenauflistung
das klingt ja nach einer Boardansicht. Scheint schwer modern zu sein, würde ich trotzdem nicht machen. Oder willst Du gleich mehrere Foren in ein Programm packen?

Mehere Foren in einem Programm. Ja das hatte ich vor. Doch mit dem richtigen Einsatz von Ordnern, die ich zum Glück auf meinem Webhoster anlegen kann, sollte das kein Problem sein. Aber erstmal werde ich das lassen.

-Threadauflistung
-Threadausgabe + Antwortenausgabe
hä? was ist denn der Unterschied zwischen "Threadauflistung
" und "Threadausgabe"?

Hm. Schlecht formuliert. Threadauflistung: Auflistung der Titel/Überschriften aller Threads eines Themas.

-Bearbeitung eigener Threads/Antworten
Boy! Nachrichten im Nachhinein als nicht-Admin verändern?

Unsicher?

Was gemeinst ist.
Der Admin kann alle Threads/Antworten editieren/löschen, der registrierte Benutzer nur seine eigen geschriebenen, und der Gast kann sowieso nichts schreiben. Es wird natürlich jedes mal der Code gesichert (d.h. nur BB-Code und alle "<" werden zu < und so weiter)

Ich selber habe mir gedacht, ich könnte eine Oberklasse erstellen die alles enthällt was alle sehen können (= unregistriert/registriert/Admin/...)
und was wäre ein Objekt davon?

ADMIN oder Gast oder Benutzer?
bzw. Ausgabe-fürden-Admin, Ausgabe-fürden-Beutzer, ...

Die Frage verstehe ich nicht ganz, aber ich formuliere es trotzdem mal anders: Die Oberklasse / Basisklasse von der geerbt wird, gibt aus was für alle sichtbar seien soll. Z.B. die Threads werden für jeden Sichtbar sein. Jedoch das Objekt Ausgabe-fürden-Admin würde noch zu jeder Ausgabe eine/s/r Threads/Antwort einen Button hinzufügen, durch den man den Thread bearbeiten/löschen kann.

und dann jeweils unterklassen für Admin - ( Benutzer hohen Grades, Benutzer mittleren Grades - ... ) - Gast.
naja, ich würde nicht gleich übertreiben, aber vom Ansatz kann ich das schon eher nachvollziehen. Ich habe z.B. eine Klasse "userdaten" - in den Objekten dieser Klasse stehen persönliche Voreinstellungen und gelesene Postings des jeweiligen Users drin.

Hm ich weiß nicht, ob ich mir etwas Richtiges dabei vorstelle, aber könntest du mal jeweils eine Funktion der beiden Objekte nennen, damit der Sinn hierbei besser erkennbar ist. Oder einfach den Sinn hier irgendwie deutlicher machen, denn mir kommen gerade dutzende Vermutungen was du eigentlich damit meinen könntest

Ich habe das ganze Forum zunächst vom User aus betrachtet. Da ist dann jeder Frame ein Objekt. In dem ListenFrame steckt das Objekt "Liste", darin steckt das Objekt "Block" (man kann meine Liste von Block zu Block blättern), darin stecken die Threads als Objekte und darin die Postings als Objekte. Bei der Anzeige eines Postings zeige ich eben dieses Objekt an. Dann habe ich auch ein Datenbankobjekt - das kann Postings holen, Postings löschen, Postings schreiben usw. Die Suche ist bei mir auch ein Objekt, das für den einzelnen Suchvorgang konstruiert wird und wo alle Infos stehen, was der User als Sucheingrenzung eingegeben hat und welche Zwischenergebnisse es gibt.

Und wass wird hierbei vererbt? Also was würden diese Objekte alle gemeinsam haben? Denn genau das ist es eigentlich was mich am meisten interessiert.

vor allem wenig durchdacht - so erscheinen mir Deine Formulierungen jedenfalls. Ich würde mir da mal einen Plan aufzeichnen.

Tut mir nochmal leid wegen der schlechten Formulierung. Aufzeichnen, hm. Ich probiers mal.

Ich habe mich bemüht diese Antwort verständlich zu fomulieren, aber ich bin mir sicher das denoch einiges Unverständlich seien wird, da Formulierung ehrlichgesagt nicht nur hier schlecht ist.

Gruß, Andreas

mfG Robert

[Andreas-Lindig]

Boy! Nachrichten im Nachhinein als nicht-Admin verändern?
Der Admin kann alle Threads/Antworten editieren/löschen, der registrierte Benutzer nur seine eigen geschriebenen

na, ich weiß ja nicht. Wir wollen hier nicht über Dein Konzept diskutieren, aber ob das sinnvoll ist, daß da einer Leute beschimpfen kann und wenn es peinliche Reaktionen gibt, dann kann er sein Ausgangsposting einfach ändern?

Ich habe z.B. eine Klasse "userdaten" - in den Objekten dieser Klasse stehen persönliche Voreinstellungen und gelesene Postings des jeweiligen Users drin.

Hm ich weiß nicht, ob ich mir etwas Richtiges dabei vorstelle, aber könntest du mal jeweils eine Funktion der beiden Objekte nennen, damit der Sinn hierbei besser erkennbar ist.

naja, "userdaten" liest zum Beispiel das ID-Cookie aus und setzt es ggf. Dann hat sie die Methode "get_voreinstellungen" - damit liest sie die Datei mit den individuellen Einstellungen und gelesenen Beiträgen des Users aus. Genauso gibt es "set_gelesen" oder "set_voreinstellungen". Oder "get_status" - an diese Methode kann man eine Posting-ID schicken und bekommt zurück, ob dieses Posting gelesen ist oder neu oder normal.

Und wass wird hierbei vererbt? Also was würden diese Objekte alle gemeinsam haben

bei mir wird nicht so viel vererbt. Nur die Klasse "posting" vererbt an "postingKurz" und "postingLang". Wie Andreas Korthaus schon schrieb gibt es ein Objekt, das nur die Kopfinformationen enthält und eines, das auch den Text und ausführlicheren Kopf enthält. Gemeinsam haben sie die Kopfdaten, und die Methoden zum holen aus der DB. Außerdem habe ich Buttons mit denen man in der Threadliste blättern kann, einen für "vor" und einen für "zurück", die haben gemeinsam, daß sie Pfeile als Bilder einbinden und die noch mögliche Anzahl der Postings aus der DB abfragen. Das steht dann in der Superklasse "Button".

In Deinem Fall wäre sicher eine Oberklasse die für die verschiedenen Nutzer, aber auch eine für die verschiedenen Foren sinnvoll. Bedenke aber, daß die ganze Vererbung in PHP noch nicht ausgereift ist. Du kannst zum Beispiel nicht wirklich auf Superklassen zugreifen oder innere Klassen bilden.

Aufzeichnen, hm. Ich probiers mal.

das finde ich immer sehr hilfreich, also so ein Baumdiagramm

Ich habe mich bemüht diese Antwort verständlich zu fomulieren

find' ich gut :)

Gruß, Andreas

[Andreas Korthaus]

Hi!

Boy! Nachrichten im Nachhinein als nicht-Admin verändern?
Der Admin kann alle Threads/Antworten editieren/löschen, der registrierte Benutzer nur seine eigen geschriebenen

na, ich weiß ja nicht. Wir wollen hier nicht über Dein Konzept diskutieren, aber ob das sinnvoll ist, daß da einer Leute beschimpfen kann und wenn es peinliche Reaktionen gibt, dann kann er sein Ausgangsposting einfach ändern?

Also so eine Diskussion habe ich noch nie irgendwo mitbekommen.

Naja, ich finde es schon sinnvoll. Zumindest wirkt das bei mir so dass ich nachher Rechtschreib-Fehler beseitigen kann, ich weiß nicht wieso, ich kann mich in einem Forum wie diesem zwar auch bemühen, aber am Ende schicke ich doch immer wieder Postings ab die ich nicht mehr kontrolliere, oder manchmal finde ich Fehler auch erst später. Oder man kann Ergänzungen machen für das Archiv...

Das ist irgendwie psychologisch bedingt, innerlich will ich das Posting immer so schnell wie möglich abschicken, und eine Vorschau/Rechtschreibprüfung kostet Zeit/ein klick extra... ja das ist sehr dumm und falsch, und man kann sich auch zusammenreißen, aber mir passiert es trotzdem immer wieder. Wenn man seinen Beitrag nachträglich editieren kann, dann kann man auch wenn man sich nicht beherrschen konnte von wegen Vorschau... die Fehler immer noch korrigieren, denn wenn der Beitrag mal abgeschickt ist ändert sich der psychische Druck irgendwie dahingehend, dass man dann einem Rechtschreibfehler... dann doch unangenehm sind, vor allem wenn das Forum doch so tolle Features wie Vorschau und Rechtschreibprüfung bietet, also ändere ich es dannach gerne :)

Mich würde interessieren wie sich eine Rechtschreibprüfung auswirken würde, die nicht mit select-Feldern funktioniert, sondern die Fehler rot unterstrichen markiert :)
Im Augenblick würde ich das als angenehmer empfinden, aber wenn ich nicht drüber nachdenke - würde ich es mehr nutzen? Ich weiß es nicht ;-)

Grüße
Andreas

[Andreas-Lindig]

...daß da einer Leute beschimpfen kann und wenn es peinliche Reaktionen gibt, dann kann er sein Ausgangsposting einfach ändern?

Naja, ich finde es schon sinnvoll. Zumindest wirkt das bei mir so dass ich nachher Rechtschreib-Fehler beseitigen kann

klar ist das angenehmer, das mache ich in meinem privat-Gästebuch auch. Aber als Admin ist das eben anders, ich bin verantwortlich und beseitige z.B. auch stillschweigend Rechtschreibfehler der Besucher.

...am Ende schicke ich doch immer wieder Postings ab die ich nicht mehr kontrolliere

die Verantwortung muß aber beim User bleiben - finde ich - sonst stellt sich die Disziplin nämlich nie ein.

oder manchmal finde ich Fehler auch erst später.

wenn Du im Ganzen sauber postest (und das tust Du) wird Dir das keiner übel nehmen.

Oder man kann Ergänzungen machen für das Archiv...

wäre natürlich manchmal sinnvoll, aber da fände ich überhaupt an erster Stelle ein aufgeräumtes, also verschlagwortetes Archiv wichtig.

Das ist irgendwie psychologisch bedingt, innerlich will ich das Posting immer so schnell wie möglich abschicken

<psychoanlyse ;)>
   nur hier oder auch in anderen Foren? - vielleicht ist das der Konkurrenzkampf mit den Anderen. Dieses Forum ist halt so furchtbar schnellebig. Ich komme meist gar nicht dazu zu antworten, weil alles schon gesagt wurde.
</psychoanalyse ;)>

Mich würde interessieren wie sich eine Rechtschreibprüfung auswirken würde, die nicht mit select-Feldern funktioniert, sondern die Fehler rot unterstrichen markiert :)

vielleicht blinkend ;)

Gruß, Andreas

[Andreas Korthaus]

Hoi!

<psychoanlyse ;)>
   nur hier oder auch in anderen Foren? - vielleicht ist das der Konkurrenzkampf mit den Anderen. Dieses Forum ist halt so furchtbar schnellebig. Ich komme meist gar nicht dazu zu antworten, weil alles schon gesagt wurde.
</psychoanalyse ;)>

Nee, das passiert mir eher weiter unten im Forum, vor allem bei längeren Postings...

Grüße
Andreas

[Andreas Korthaus]

Hallo!

-Themenauflistung
-Threadauflistung
-Threadausgabe + Antwortenausgabe
-Regiestrier Möglichkeit
-Login
-Mehrere Themen
-Bearbeitung eigener Threads/Antworten
-verschiedene User mit verschiedenen Rechten

Ich selber habe mir gedacht, ich könnte eine Oberklasse erstellen die alles enthällt was alle sehen können (= unregistriert/registriert/Admin/...)

und dann jeweils unterklassen für Admin - ( Benutzer hohen Grades, Benutzer mittleren Grades - ... ) - Gast.

Nein, sowas würde ich nicht machen. Versuche eher mal die Objekte aus der der Realität zu modellieren.

Da wären zum einen die User, von denen gibt es 3 verschiedene. Viele SAchen sind bei allen Usern gleich, also alle haben einen usernamen, alle ein Passwort, brauchen eien Methode zum erzeugen, löschen...
und einige User haben besondere Eigenschaften und methoden, z.B. der Admin.

Also würde ich hier mal eine Klasse "User" vorschlagen, und 3 von User erbende Klassen "Admin","Guest","RegisteredUser" oder sowas.

Dann hast Du auf der anderen Seite Threads und Postings, wobei man im Thread-Objekt auch eine Liste mit Referenzen auf die zugehörigen Postings verwenden kann, oder man verwendet eine extra-Klasse für die Zuordnung. So eine Klasse Thread könnte eine Methode "getPostingList()" haben, die die zugehörigen PostingIDs zurückgibt, mit denen Du dann die Posting-Objekte erzeugst, die dann wieder Methoden haben die die entsprechenden Daten für die Ausgabe zurükgeben. Eine andere Variante, die ich vermutlich bevorzugen würde wäre, wenn das Thread-Objekt eine Methode hätte wie fetchPostings(), welche entsprechend die Postings recht performant aus der DB auslesen kann, und der Reihe nach alle Posting-Objekte erzeugen kann. Und dabei die Objekte nur so weit füllen wie sinnvoll/notwendig, bei der Posting-Übersicht braucht man z.B. noch nicht den kompletten Text jedes Postings...

Vielleicht macht auch eine Klasse "Forum" Sinn, die Referenzen auf die Threads enthält. Das Forums-Objekt könnte eine Methode haben wie "getThreadList()", die dann eine entsprechende Liste der Threads zurückgibt, aus der Du die Liste basteln kannst. Oder Du kannst irgendwo eine methode displayThreadList() haben, die das ganze erledigt.
Und wenn Du ein bisschen überlegst findest Du vielleicht noch mehr sinnvolle Objekte.

Da PHP ja leider die Objekte nicht persistent im Speicher hält, und da das bei größeren Datenmengen sowieso nicht geht, musst Du allerdings Kompromisse eingehen. Daher würde ich evtl. nicht überall Referenzen auf existierende Objekte speichern, sondern vielleicht einfach auf eine entsprechende ID, anhand der Du das entsprechende Objekt erzeugen kannst. Oder Objekte immer nur so weit füllen wie Du die Daten brauchst...

Dann solltest Du noch drauf achten, dass Du die Präsentation von der Datenhaltung trennst. Das funktioniert z.B. hervorragend durch Verwendung einer Template-Engine für die Präsentation der Daten, und/oder auf der anderen Seite durch Verwenden von Data-Access-Objects, das heißt in der "Business-Logik" änderst Du nur die Eigenschaften von Objekten, und führst entsprechende Änderungen in der Datenbank selbst über spezielle Objekte/Methoden durch.

Aber versuche nicht alles auf einmal, das wichtigste ist dass Du ein Verständnis für die oben genannten Objekte bekommst, die aus der Realität, denn das ist IMHO der beste Weg OOP zu verstehen, nicht das sture verwenden von Klassen und Objekten nur weil man glaubt es zu brauchen oder weil es andere auch machen.

Jedenfalls gibt es immer viele Wege, man muss einfach mal anfangen und Erfahrungen sammeln. Vielleicht würde ich es alles doch ganz anders machen wenn ich länger drüber nachdenke ;-)

Und die rollen-abhängigen Sachen, das ist recht einfach in der Klasse User zu implementieren. Einfach eine Methode isAdmin() und eine isRegisteredUser(), und entsprechend prüfen wenn da was rollen-abhängig angezeigt oder verändert werden soll.

Wie würdet ihr hier das OOP ausnutzen?

Ehrlich gesagt kommt mir meine Variante als nicht zu sinvoll vor, ob das wahr ist würde sich herausstellen wenn ich das forum mal auf diese Weise mächte.

Sollte ich es überhaupt ausprobieren oder hat das überhaupt keine Sinn eurer Erfahrung nach.

Auf jeden Fall, und Du solltest einiges zu OOP lesen.
Vielleicht nicht nur von PHP, sondern auch von anderen Sprachen, z.B.: http://java.sun.com/docs/books/tutorial/java/concepts/index.html

Aber auch für PHP gibt es gute Arikel...
http://www.php-mag.net/itr/online_artikel/show.php3?id=284&p=0&nodeid=114

Ach ja, noch eine Grundregel, greife NIEMALS von außen auf eine Klassen-Variable direkt zu, also nicht sowas:

class Test {
  var $intern;
}
$test = new Test;
$test->intern = 'SO NICHT';
echo $test->intern;

sowas nicht machen!

Nur so:

class Test {
  var $intern;

function setBla($new_val) {
    $this->intern = $new_val;
  }
  function getBla() {
    return $this->intern;
  }
}
$test = new Test;
$test->setBla('NUR SO');
echo $test->getBla();

Viele Grüße
Andreas

[Robert]

Hallo!

Versuche eher mal die Objekte aus der der Realität zu modellieren.

Das ist mal ein sehr schöner Tipp. Werde es auf jedenfall so probieren.

Da wären zum einen die User, von denen gibt es 3 verschiedene. Viele Sachen sind bei allen Usern gleich, also alle haben einen usernamen, alle ein Passwort, brauchen eien Methode zum erzeugen, löschen...
und einige User haben besondere Eigenschaften und methoden, z.B. der Admin.

^^^^^^^^^
|||||||||
mit Objekten aus der Realität modelliert.
Auch ein sehr schöner Tipp es so anzugehen.

Dann hast Du auf der anderen Seite Threads und Postings, wobei man im Thread-Objekt auch eine Liste mit Referenzen auf die zugehörigen Postings verwenden kann, oder man verwendet eine extra-Klasse für die Zuordnung. So eine Klasse Thread könnte eine Methode "getPostingList()" haben, die die zugehörigen PostingIDs zurückgibt, mit denen Du dann die Posting-Objekte erzeugst, die dann wieder Methoden haben die die entsprechenden Daten für die Ausgabe zurükgeben.

Gefallt mir gut. Warum?:
Es wird im Objekt Thread eine Methode geben, die die IDs der zugehörigen Postings/Antworten, zurück gibt z.B. in einem Array. Diese Methode ist aber in meinem Fall nicht notwendig, da die zugehörigen postings die selbe Id kriegen werden wie der Thread. Eine Methode könnte mir aber die ID des Objektes zurückgeben.

Ich könnte jetzt eigentlich die Postings zu dem Thread einfach mit einer Funktion ausgeben lassen. Aber mit einem extra Objekt Posting könnt ich noch eine extra Methode zum Testen des zum ausgebenden Textes hinzufügen. Vielleicht eine die Wörter die üüüüüüüüüüüüüüüüüüübbbbbbbbbberlang sind zerschneidet.
Ob das gut gedacht ist, werde ich ja spätestens bemerken wenn ich mal das Forum gemacht habe.
Daweil könnte ich das auch ohne Objektorientierung aber ich will sie einfach mal testen ob es nützlich ist in Sachen: leichtes Ändern des Quellcodes, kürzerer/übersichtlicher Quellcode... .

Eine andere Variante, die ich vermutlich bevorzugen würde wäre, wenn das Thread-Objekt eine Methode hätte wie fetchPostings(), welche entsprechend die Postings recht performant aus der DB auslesen kann, und der Reihe nach alle Posting-Objekte erzeugen kann. Und dabei die Objekte nur so weit füllen wie sinnvoll/notwendig, bei der Posting-Übersicht braucht man z.B. noch nicht den kompletten Text jedes Postings...

Das muss ich mal gut Überdenken.

Wenn Du ein bisschen überlegst findest Du vielleicht noch mehr sinnvolle Objekte.

Das probiere ich schon die ganze Zeit.

Daher würde ich evtl. nicht überall Referenzen auf existierende Objekte speichern, sondern vielleicht einfach auf eine entsprechende ID, anhand der Du das entsprechende Objekt erzeugen kannst.

Wenn das Objekt Posting z.B. einen Konstruktor hat, der einen Parameter verlangt, welcher die ID des Postings sein soll, wird es sowieso nur nötig sein die IDs zu Speichern.

Dann solltest Du noch drauf achten, dass Du die Präsentation von der Datenhaltung trennst. Das funktioniert z.B. hervorragend durch Verwendung einer Template-Engine für die Präsentation der Daten, und/oder auf der anderen Seite durch Verwenden von Data-Access-Objects, das heißt in der "Business-Logik" änderst Du nur die Eigenschaften von Objekten, und führst entsprechende Änderungen in der Datenbank selbst über spezielle Objekte/Methoden durch.

Muss ich auch mal überdenken. Ich habe keine Datenbank zur Verfügung. Ich arbeite mit PHP Dateien, die Assoziative Arrays, welche alle Eingaben enthalten, haben. Natürlich sind alle Postings und Antworten und Userdaten aus Präsentation nicht in eine Datei gestopft.

Aber versuche nicht alles auf einmal, das wichtigste ist dass Du ein Verständnis für die oben genannten Objekte bekommst, die aus der Realität, denn das ist IMHO der beste Weg OOP zu verstehen, nicht das sture verwenden von Klassen und Objekten nur weil man glaubt es zu brauchen oder weil es andere auch machen.

Ich meine ich habe die oben genannten Objekte und der Sinn Verstanden. Es kann aber auch sein, dass ich das ganze anders als ich soll verstanden habe aber irgendwann wirds schon werden glaub ich. Ich probiere erstmal die beiden Verweise, die du mir geschickt hast, aus.

Und die rollen-abhängigen Sachen, das ist recht einfach in der Klasse User zu implementieren. Einfach eine Methode isAdmin() und eine isRegisteredUser(), und entsprechend prüfen wenn da was rollen-abhängig angezeigt oder verändert werden soll.

Ich bevorzuge hier den einzelnen Usern Grade zu geben, die dann in einem Assoziativen Array $USER["grad"] sind. Z.B. Nach der Prüfung der Login-Eingaben des Users, wird ein Array USER erstellt, welches die Daten zum Aktuellen User, die ebenfalls in Assoziativen Array enthalten sind, zugewiesen bekommt. Zu den Daten der User gehören auch ihre Grade. siehe hier:

Erst sind von jedem USER die Daten in DBs bzw. php Dateien gespeichert.

$DATEN["DerRobert"]["name"] = "Robert";
$DATEN["DerRobert"]["nick"] = "DerRobert";
$DATEN["DerRobert"]["passwd"] = "12345";
$DATEN["DerRobert"]["grad"] = "1";
...

Wenn sich der User jetzt mit den nick DerRobert mit einem passwort  versucht einzuloggen, wird getesteten ob

$DATEN["DerRobert"]["passwd"] == passwort

ist und bei true passiert dann:

$USER = $DATEN["DerRobert"]

=>
$USER["name"]= "Robert";
$USER["nick"] = "DerRobert";
$USER["grad"] = "1";
...

Admins bekommen den Grad 1
Benutzer den Grad 2
Gäste den Grad 3

Wenn nun etwas nur vom Admin und Benutzer durchgeführt werden soll benutze ich diese Bedingte Anweisung:

if($USER["grad"]<=2)
{
...
}

http://java.sun.com/docs/books/tutorial/java/concepts/index.html

http://www.php-mag.net/itr/online_artikel/show.php3?id=284&p=0&nodeid=114

Java kann nciht schaden.
Werde ich mir jetzt mal durchlesen!

$test = new Test;
$test->intern = 'SO NICHT';
echo $test->intern;

hatte ich nie vor :)
Finde ich schade.

Ich bedanken mich für deine Hilfen/Tipps und für deine ausführlichen Antworten.

Guten Tag/Sonntag
mfG Robert

[Andreas Korthaus]

Hallo!

Daweil könnte ich das auch ohne Objektorientierung aber ich will sie einfach mal testen ob es nützlich ist in Sachen: leichtes Ändern des Quellcodes, kürzerer/übersichtlicher Quellcode... .

Es ist sicher nicht immer kürzer, kommt drauf an. Aber wenn man es vernünftig macht ist es sicher einfacher zu warten, zu erweitern und besser verständlich. Und das sollte das Ziel sein.

Daher würde ich evtl. nicht überall Referenzen auf existierende Objekte speichern, sondern vielleicht einfach auf eine entsprechende ID, anhand der Du das entsprechende Objekt erzeugen kannst.

Wenn das Objekt Posting z.B. einen Konstruktor hat, der einen Parameter verlangt, welcher die ID des Postings sein soll, wird es sowieso nur nötig sein die IDs zu Speichern.

Ja, aber Referenzen auf Objekte zu speichern ist natürlich elegant ;-)

Muss ich auch mal überdenken. Ich habe keine Datenbank zur Verfügung.

Um so besser, das umgeht einige Probleme/Versuchungen ;-)
Dann wäre es natürlich ne ganz gute Übung die Threads in XML-Dateien zu speichern, ist natürlich wieder ein größeres Thema ;-)

Ich arbeite mit PHP Dateien, die Assoziative Arrays, welche alle Eingaben enthalten, haben. Natürlich sind alle Postings und Antworten und Userdaten aus Präsentation nicht in eine Datei gestopft.

Du könntest auch die Objekte selber serialisiert speichern, vielleicht ein Verzeichnis "Threads" und ein Verzeichnis "Postings", und dann pro Thread eine Datei mit der ThreadID als Namen, entsprechend für die Postings. Dann kannst Du über die ID die entsprechende Datei öffnen, das entsprechende Objekt wiederherstellen, kannst sie anzeigen, oder verändern udn wieder speichern...
Ist nur später nicht so gut veränderbar, naja.

Und die rollen-abhängigen Sachen, das ist recht einfach in der Klasse User zu implementieren. Einfach eine Methode isAdmin() und eine isRegisteredUser(), und entsprechend prüfen wenn da was rollen-abhängig angezeigt oder verändert werden soll.

Ich bevorzuge hier den einzelnen Usern Grade zu geben, die dann in einem Assoziativen Array $USER["grad"] sind. Z.B. Nach der Prüfung der Login-Eingaben des Users, wird ein Array USER erstellt, welches die Daten zum Aktuellen User, die ebenfalls in Assoziativen Array enthalten sind, zugewiesen bekommt. Zu den Daten der User gehören auch ihre Grade. siehe hier:

Erst sind von jedem USER die Daten in DBs bzw. php Dateien gespeichert.

$DATEN["DerRobert"]["name"] = "Robert";
$DATEN["DerRobert"]["nick"] = "DerRobert";
$DATEN["DerRobert"]["passwd"] = "12345";
$DATEN["DerRobert"]["grad"] = "1";
...

Das ist aber keine OOP.

OOP wäre sowas

$User = new User("DerRobert");
echo $User->getNick(); // DerRobert
echo $User->getName(); // Robert
echo $User->isAdmin(); // FALSE
echo $User->isRegisteredUser(); // TRUE

Wenn nun etwas nur vom Admin und Benutzer durchgeführt werden soll benutze ich diese Bedingte Anweisung:

if($USER["grad"]<=2)
{
...
}

if($User->isAdmin()) {
  ...
}

$test = new Test;
$test->intern = 'SO NICHT';
echo $test->intern;

hatte ich nie vor :)
Finde ich schade.

Jetzt findest Du es schade, später handelst Du Dir aber Probleme ein wenn Du Dich nichts dran hälst.

Viele Grüße
Andreas

[asdf (Robert)]

Hallo!

Ja, aber Referenzen auf Objekte zu speichern ist natürlich elegant ;-)

:)

Ich arbeite mit PHP Dateien, die Assoziative Arrays, welche alle Eingaben enthalten, haben. Natürlich sind alle Postings und Antworten und Userdaten aus Präsentation nicht in eine Datei gestopft.
Du könntest auch die Objekte selber serialisiert speichern, vielleicht ein Verzeichnis "Threads" und ein Verzeichnis "Postings", und dann pro Thread eine Datei mit der ThreadID als Namen, entsprechend für die Postings. Dann kannst Du über die ID die entsprechende Datei öffnen, das entsprechende Objekt wiederherstellen, kannst sie anzeigen, oder verändern udn wieder speichern...
Ist nur später nicht so gut veränderbar, naja.

Meiner Meinung nach nicht. Es wäre sogar ziemlich einfach da ich sowieso wie immer nur die ID vom Posting/Thread brauche um den inhalt zu ändern mit einem Script. Noch dazu muss ich nicht jedes mal alle threads bzw. postings mit include laden damit ich 10 davon auslesen kann.
Ich wollte gerade etwas fragen in SELFHTML und da die Frage aber hier hervorragend dazu passt werde ich sie einfach hier stellen.

Ist es schlecht für jeden Registrierten eine Datei anzugeben? Ich meine ist es nicht schlimm wenn bspielsweise 100 dateien sich in einem ordner befinden? Das würde nähmlich meine Arbeit ungemein bequem machen.

Erst sind von jedem USER die Daten in DBs bzw. php Dateien gespeichert.

$DATEN["DerRobert"]["name"] = "Robert";
$DATEN["DerRobert"]["nick"] = "DerRobert";
$DATEN["DerRobert"]["passwd"] = "12345";
$DATEN["DerRobert"]["grad"] = "1";
...

Das ist aber keine OOP.

OOP wäre sowas

Manchmal vergisst man, dass man OO arbeiten wollte. :)

$User = new User("DerRobert");
echo $User->getNick(); // DerRobert
echo $User->getName(); // Robert
echo $User->isAdmin(); // FALSE
echo $User->isRegisteredUser(); // TRUE

Das sieht schön angenehm aus.

Wenn nun etwas nur vom Admin und Benutzer durchgeführt werden soll benutze ich diese Bedingte Anweisung:

if($USER["grad"]<=2)
{
...
}

if($User->isAdmin()) {
  ...
}

falsch denn es soll von Admin _und_ Registrierten Benutzer durchgeführt werden also
if($User->isAdmin() || $USER->idRegUser())
{
 Anweisungen
}

Jetzt findest Du es schade, später handelst Du Dir aber Probleme ein wenn Du Dich nichts dran hälst.

Hoffentlich bald :)

Danke nochmal für die Verweise java habe ich mir noch nciht angeschaut aber das mit php ist ganz nett.

Grüße
Robert