timo hat geschrieben:Eigentlich nicht...das Problem ist, daß das Backend den Kategoriebaum zwischenspeichert, dafür gibt es die Session-Variable remakeStrTable. Wenn diese "true" ist, wird der Baum im Backend neu erzeugt. Ich weiß nicht, ob man vom Frontend aus sämtliche Sessions mit dieser Variable "bestücken" könnte (ist sicherlich möglich, aber die Frage ist, ob das nicht zu Imperformant ist).
Geht nur um's Backend. Im Frontend soll der Baum schön so bleiben wie er ist
. Hintergrund bei mir: Ich arbeite mit einer zweiten Datenbank, deren Elemente teilweise durch Kategorien repräsentiert werden, deshalb muss ich an den Kategorienbaum ran. Ich sehe jetzt aber auch meinen Denkfehler: Da ich mit zwei Benutzern arbeite, ist es ganz klar, dass der zweite Benutzer in seinem Backend nichts mitbekommt, wenn der erste Benutzer den Baum geändert hat. Bei dem ändernden Benutzer funktioniert es wunderbar (wenn auch nur mit Rechtsklick und "aktualisieren" und nicht automatisch, aber das kann ich verschmerzen).
timo hat geschrieben:Eigentlich müsste man das ganze Konstrukt "Kategorienanzeige bei Artikel und Kategorien" komplett wegwerfen und neu implementieren...
Jepp, denn wenn ich das richtig sehe, wird, wenn zwei Leute parallel arbeiten und einer den Kategorienbaum ändert, der andere nichts davon mitbekommen ...
Wäre vielleicht besser, bei Änderungen am Kategorienbaum in die Datenbank eine Prüfsumme zu schreiben (z.B. in cat_tree, die Prüfsumme in idcat mit dem Schlüssel 0 in idtree) und erst immer nur die Prüfsumme zu laden. Nur wenn die sich vom gespeicherten Wert unterscheidet, wird der gespeicherte Baum verworfen und neu aufgebaut. Sollte auch noch performant sein, reflektiert aber auch Änderungen anderer Benutzer ...
...