Optimierung pages-Tabelle / Tree
Verfasst: Mo 6. Aug 2018, 17:23
Punkt 1: Optimierung pages-Tabelle
Spalte "language" -> derzeit Text (z.B. "DE"), könnte aber auf addons-Tabelle verlinken
Spalte "template" -> desgleichen
Spalte "menu" -> Zur Diskussion: Vielleicht macht es Sinn, für Menüs eine eigene Tabelle mit Einstellungen einzurichten? Dann würde hier die ID des Menüs stehen, also ein Foreign Key. Hätte den netten Nebeneffekt, dass Menüs über eine grafische Oberfläche administrierbar wären und man keine lustigen Aufrufe mit 30 Parametern im Template bräuchte. Nur noch "{showmenu(<ID>)}" und alles andere macht ein Admintool.
Punkt 2: Tree
Baumstrukturen sind immer eine haarige Angelegenheit. Es gibt diverse Algorithmen, angefangen von "Adjacency Lists" - das ist das was wir machen - über Closure Tables zu Nested Sets. Alle haben ihre Vor- und Nachteile und ihre Daseinsberechtigung. Bei allen kriegt man irgendwann einen "Buffer overflow" im Hirn.
Das Problem ist, dass wir beispielsweise den Seitenbaum nicht nur aus der Datenbank auslesen und darstellen müssen, sondern diverse Eigenschaften damit verbinden. Beispiele:
Meine Überlegung: Aus dem Seitenbaum einen "echten" Baum machen. https://github.com/nicmart/Tree
Eigenschaften wie "isLeaf()" (letztes Element im Pfad), "hasChildren()" (es gibt Unterseiten), "isRoot()" (es ist eine Level-0-Seite) etc. können dann zu dem Zeitpunkt aufgerufen werden, wenn sie wirklich gebraucht werden.
Spalte "language" -> derzeit Text (z.B. "DE"), könnte aber auf addons-Tabelle verlinken
Spalte "template" -> desgleichen
Spalte "menu" -> Zur Diskussion: Vielleicht macht es Sinn, für Menüs eine eigene Tabelle mit Einstellungen einzurichten? Dann würde hier die ID des Menüs stehen, also ein Foreign Key. Hätte den netten Nebeneffekt, dass Menüs über eine grafische Oberfläche administrierbar wären und man keine lustigen Aufrufe mit 30 Parametern im Template bräuchte. Nur noch "{showmenu(<ID>)}" und alles andere macht ein Admintool.
Punkt 2: Tree
Baumstrukturen sind immer eine haarige Angelegenheit. Es gibt diverse Algorithmen, angefangen von "Adjacency Lists" - das ist das was wir machen - über Closure Tables zu Nested Sets. Alle haben ihre Vor- und Nachteile und ihre Daseinsberechtigung. Bei allen kriegt man irgendwann einen "Buffer overflow" im Hirn.

Das Problem ist, dass wir beispielsweise den Seitenbaum nicht nur aus der Datenbank auslesen und darstellen müssen, sondern diverse Eigenschaften damit verbinden. Beispiele:
- Aktuelle Seite im Menü markieren
- Alle direkt übergeordneten Seiten der aktuellen Seite markieren ("Ancestors")
- Nur Seiten auf der gleichen Ebene anzeigen ("Siblings")
- Nur nachgeordnete Seiten einer Seite anzeigen ("Descestors" oder "Children")
- Pfad zur Seite anzeigen ("Breadcrumb")
Meine Überlegung: Aus dem Seitenbaum einen "echten" Baum machen. https://github.com/nicmart/Tree
Eigenschaften wie "isLeaf()" (letztes Element im Pfad), "hasChildren()" (es gibt Unterseiten), "isRoot()" (es ist eine Level-0-Seite) etc. können dann zu dem Zeitpunkt aufgerufen werden, wenn sie wirklich gebraucht werden.