PHP: In Objekt eine Liste von Verweisen auf untergeordnete Objekte

[Marcel]

Hallo!

Ich mag momentan nicht glauben, dass folgendes in PHP nicht gehen soll, obwohl das doch eine OOP-Sprache sein will:

Ich möchte einen Baum programmieren.
Sprich, ich baue eine Klasse treenode.
Jene soll neben einer Eigenschaft "Beschriftung" auch Verweise auf untergeordnete Nodes enthalten.
Also in etwa so:

class treenode {
var $id;
var $beschriftung;
var $childnodes;
var $parentnode;
}

$parentnode sollte dann ein Verweis auf den Papaknoten sein, $childnodes eine Liste von Verweisen auf Kindknoten.
Dann soll (falls die Objekte existieren) folgendes möglich sein:

print $EinEnkelknoten->parentnode->parentnode->beschriftung;
foreach($EinKnoten->childnodes as $Knoten){
print $Knoten->Beschriftung;
}


Suche jetzt schon seit 'ner halben Stunde das Netz ab, finde aber keinen Hinweis darauf, dass das möglich ist. Geht das tatsächlich nicht?

Gruß,
Marcel

[Marcel]

Hm, mit dem Baum wollte ich hierarchische Daten aus 'ner DB (Kommentare und Antworten auf Kommentare und Antworten auf Antworten auf Kommentare und Antworten auf Antworten auf Antworten auf Kommentare und...) in 'nen Baum packen und den dann ausgeben.

Habe mir jetzt - von PHP enttäuscht und auf PHP5 gespannt - damit beholfen, die Daten direkt, ohne sie zwischenzuspeichern, rauszupusten. Schön ist das aber nicht.

Gruß,
Marcel

[grakaman]

mosche

irgendwie ähnelt die frage der, die mal captain america hier gestellt hat. nur bei dir versteh ichs weniger, weil die objekte in php eh zerstört werden, wenn die page geparst ist und zum client geschickt wurde. höchstens du willst die daten mehrere male in der php page benutzen, aber dann kannst du doch die logik auch in eine klasse schreiben. wenn er dann beim objektaufruf halt zb. immer nen db zugriff macht oder aus nem file das holt, macht das bei nem gb wirklich keinen merkbaren performanceverlust. ich kenn mich nicht so dolle mit php aus, aber bei asp.net gibts zb. datasets, die die daten relational im speicher halten. du arbeitest bei asp.net immer verbindungslos und kannst dort auch xml files oder irendwas anderes an die datasets binden. vielleicht gibts bei php ja auch irgend n xml klasse oder sowas, die das macht. jedenfalls wäre das der startpunkt, wo ich suchen würde. ansonsten musst du wohl händisch da eine klasse mit arrays schreiben, was natürlich voll der umstand ist.

mfg

[Marcel]

Im Endeffekt wollte ich durch diese strukturell saubere Zwischenspeicherung der Daten nur die Programmierung übersichtlicher machen, mehr wollte ich gar nicht erreichen. Dass die Daten nach Ausführung des Skripts weg sind, war mir durchaus klar (obschon ich auch bei meiner Recherche darauf gestoßen bin, dass man auch Objekte in einer Session persistent halten kann, was ich aber erst glaube, wenn ich's sehe).

Gruß,
Marcel

[grakaman]

jo, objekte kannst du in sessions speichern. geht jedenfalls bei asp.net und hundert pro auch bei php, denk ich. nur ist das nicht so zu empfehlen, vor allem bei vielen daten nicht. sowas wie connection objekte etc. kannst du bedenkenlos in sessions speichern, aber ganze datentabellen würde ich abraten. aber wie gesagt, ich würde mal nachschauen, ob es irgend welche xml klassen gibt, was anderes würde mir bei php jetzt nicht einfallen. dann speicherst halt die daten in nem xml file oder erstellst aus einer db ein xml file. vielleicht gibts in php auch eine klasse, die die daten aus einer datenbank auch so schon im xml format im speicher hält.

mfg

[Tommes]

Hier mal was zu lesen:

Objekte in Sessions speichern (http://phpug.ch/codereview/original.php?id=20&PHPUGSESSID=11e324b493960a9b320aed983818bb6f)

Nested Sets (Verschachtelte Mengen) mit SQL (http://www.php-resource.de/tutorials/read/21/1/)

Das sollte alle deine Fragen beantworten, bin zu schreibfaul ;)

[Captain America]

Warum speicherst du eigentlich Kinder und Vater im Treenode? Nur Vater ist üblicher.

[Marcel]

Originally posted by Captain America
Warum speicherst du eigentlich Kinder und Vater im Treenode? Nur Vater ist üblicher.

??
Ich wollte jedes Familienmitglied in einem eigenen Knoten speichern.
Hat sich (zumindestens dieser konkrete Fall) lang erledigt. Finde PHP's OOP hier nur arg beschränkt.

[Captain America]

Neeeiiinn ich meine, wenn du eine Klasse Treenode baust, dann hat die normal nicht Childnodes, sondern nur Parentnodes:


class treenode
{
var $id;
var $parentId;
var $label;
}



Dann gehst du im Programm vom Rootnode aus, und per Schleife rufst du immer die Kindernodes auf, die du anhand der $parentId herausfindest. Eine Redundanz auch die Kinder zu speichern ist irgend wie unnötig.

Und ich halte PHP generell für beschissen, sobald es um grosse Projekte geht. Es kann kein OOP, es kann nicht mal try-catch-blöcke (Exceptions), es ist auch nicht auf OOP aufgebaut (siehe Funktionen anstatt Objekte mit Methoden, wie strlen() und nicht String.length()).

PHP: :pukeface:

[Xmas]

Originally posted by Captain America
Dann gehst du im Programm vom Rootnode aus, und per Schleife rufst du immer die Kindernodes auf, die du anhand der $parentId herausfindest. Eine Redundanz auch die Kinder zu speichern ist irgend wie unnötig.
Redundant ist es schon, aber eine Suchschleife zu schreiben um die Childnodes zu finden ist schon ein bisschen albern, wenn man sie auch gleich dazu speichern kann. Es kommt wohl nur selten auf jedes Byte an.

[Marcel]

Originally posted by Captain America
Neeeiiinn ich meine, wenn du eine Klasse Treenode baust, dann hat die normal nicht Childnodes, sondern nur Parentnodes:


class treenode
{
var $id;
var $parentId;
var $label;
}



Dann gehst du im Programm vom Rootnode aus, und per Schleife rufst du immer die Kindernodes auf, die du anhand der $parentId herausfindest. Eine Redundanz auch die Kinder zu speichern ist irgend wie unnötig.


Hm. Wie komme ich denn an alle Objete ran, um sie zu fragen, ob deren $parentId gleich einer bestimmten ID ist? Zudem ist das auch alles andere als performant, wenn die Bäume größer werden. onnööö, in meinen Augen macht's schon Sinn, die Child-IDs zu speichern. Habe mich aber, das muss ich dazusagen, noch nicht viel mit OOP in PHP beschäftigt.

Originally posted by Captain America
Und ich halte PHP generell für beschissen, sobald es um grosse Projekte geht. Es kann kein OOP, es kann nicht mal try-catch-blöcke (Exceptions), es ist auch nicht auf OOP aufgebaut (siehe Funktionen anstatt Objekte mit Methoden, wie strlen() und nicht String.length()).

PHP: :pukeface:

Kennst Du Python? Da ist alles als Objekt abgebildet. Könnte Dein Fall sein. Für größere Projekte mit 'ner Skriptsprache vor allem.

[grakaman]

wofür brauchst du das denn genau? wenn man das genaue einsatzgebiet wüsste, könnte man ev auch andere, performantere lösungen einsetzen.

mfg

[Marcel]

Originally posted by grakaman
wofür brauchst du das denn genau? wenn man das genaue einsatzgebiet wüsste, könnte man ev auch andere, performantere lösungen einsetzen.

mfg

Originally posted by Marcel
Hm, mit dem Baum wollte ich hierarchische Daten aus 'ner DB (Kommentare und Antworten auf Kommentare und Antworten auf Antworten auf Kommentare und Antworten auf Antworten auf Antworten auf Kommentare und...) in 'nen Baum packen und den dann ausgeben.

Habe mir jetzt - von PHP enttäuscht und auf PHP5 gespannt - damit beholfen, die Daten direkt, ohne sie zwischenzuspeichern, rauszupusten. Schön ist das aber nicht.

Gruß,
Marcel

Mit "Schön" meinte ich den Programmierstil.

[grakaman]

gut, wenns bloß für ein gästebuch ist, dann kann man das auch anders lösen.
du machst eine tablle in deiner db mit den folgenden wichtigen spalten: positionsnummer, tiefe, text. Gegenbenenfalls kannst du auch noch eine Spalte RefID reinschreiben, damit du sicher gehst, worauf sich welches Post bezieht. brauchen tust du das aber nicht bei meinem beispiel. die idee ist jetzt folgende: es ist nicht wichtig zu wissen, auf welche id sich welches posting bezieht sondern wie es sortiert ist. die spalte positionsnummer gibt genau die position an, wo das posting steht. dabei spielen parentposts und childposts keine rolle, alles wird von oben nach unten exakt durchnummeriert. und für jedes child oder subchild :D post zählst du in der spalte tiefe eins hoch.
du machst also nur ein einziges select auf die tabelle mit order by positionsnummer und checkst dann eben beim ausgeben, ob in der tiefe spalte etwas >0 drin steht. wenn ja, dann kannst du das ja beliebig einrücken, je nach tiefe halt. wenn du also ein neues posting dann einfügen willst, dann checkst du worauf sich das neue posting bezieht, also welche positionsnummer. dann machst du eben ein update auf alle positionsnummer, die größer als das des postings ist, worauf du dich beziehst und zählst die um eins hoch (zb. update spalte = spalte + 1 where spalte > wert). danach fügst du das neue posting ein mit der freigewordenen positionsnummer und nun ist wieder alles perfekt durchsortiert.
also für reine foren oder gästebücher finde ich die methode wesentlich performanter und leichter als sich auf applikationsebene zu verrenken. habe auch schon sowas als forum für jemanden in php früher erstellt, funktioniert prima.

mfg

[Marcel]

Hört sich nicht schlecht an.
Allerdings habe ich keinen Einfluss auf die Datenstruktur; die steht bereits und ist Deiner Lösung im Weg.
Zudem ist dieses konkrete Beispiel bereits fertig programmiert, und was nur einmal bezahlt wird, wird auch nur einmal gebaut... ;)
Wenn ich sowas komplett neu aufbauen sollte, würde ich allerdings so oder ähnlich vorgehen.