kategoriehierarchie

[kummer]

wie steht es eigentlich bei der weiterentwicklung hinsichtlich der abbildung der kategorienhierarchie aus? für eine vereinfachung der abfragen für die navigation, artikellisten sowie breadcrumps hättte ich zwei vorschläge zu machen (oder wünsche, wie man's nimmt):

(1) es wäre günstig, wenn die hierarchie in der con_tree als nested sets abgebildet werden würde (http://de.wikipedia.org/wiki/Nested_Set). das würde die komplexität bei abfragen verringern und wäre zudem noch wesentlich schneller.

(2) ich würde ausserdem die kategoriereihenfolge auf basis eines sortierfeldes machen, statt - wie bisher - mit preid und postid. für die rückwärtskompatiblität könnte man das bisherige system ja noch belassen und ein sortierkriterium zusätzlich einfügen.

gruss,
andreas

[Dodger77]

(1) es wäre günstig, wenn die hierarchie in der con_tree als nested sets abgebildet werden würde (http://de.wikipedia.org/wiki/Nested_Set). das würde die komplexität bei abfragen verringern und wäre zudem noch wesentlich schneller.

Kann ich nur unterstützen. Bei einem Plugin habe ich eine Kategorisierung mit folgendem Ansatz umgesetzt:

http://www.thundernail.de/projekt.php?u ... t=one&id=6

Sehr chic und bei der Ausgabe extrem performant.

Habe damals beim letzten Communido und danach auch mal mit HerrB darüber gesprochen, ob sich das nicht für die Contenido-Kategorien umsetzen ließe.

(2) ich würde ausserdem die kategoriereihenfolge auf basis eines sortierfeldes machen, statt - wie bisher - mit preid und postid. für die rückwärtskompatiblität könnte man das bisherige system ja noch belassen und ein sortierkriterium zusätzlich einfügen.

Wird die Reihenfolge nicht schon durch die Nested Sets mit abgebildet?

[kummer]

Wird die Reihenfolge nicht schon durch die Nested Sets mit abgebildet?

klar. die zweite position kann also geslöscht werden. aber das andere wäre hübsch...

[kummer]

@dodger77: mit dieser klasse sollte eine anpassung ein klacks sein. oder wie schätzt du die situation ein?

[Dodger77]

Ich habe mir damals den Spaß mal ein wenig angeschaut und der Backend-Code für die Kategorien (also z.B. auch bei den Artikeln, bei der Dateiverwaltung wegen der Linkwahl für TinyMCE und co., ..) müsste dafür ein wenig angepasst werden.
Sollte an sich nicht schwierig sein, aber da steckt schon ein ordentlicher zeitlicher Aufwand hinter, denke ich. Außerdem müsste man sich IMO dann auch noch etwas für die Berechtigungen überlegen. Das könnte bei größeren Mengen von Kategorien auch etwas "bremsend" wirken. Aber da gibt es ja bereits Planungen, soweit Holger das geschrieben hatte.


Gruß

Ingo

[kummer]

ich habe mal was gemacht. zunächst eine klasse zu verwaltung der nested sets, die nativ mit der aktuellen db-klasse zusammenarbeitet. darauf aufbauend habe ich eine datei erstellt, die beim aufruf die erforderlichen zwei attribute lft und rgt erstellt und füllt.

das ganze kann man hier herunterladen: http://www.editio.ch/cms/front_content. ... uleView=52

wenn man - wie beschrieben - die datei einmal mit den browser angesprochen hat, sind die nested sets erstellt und können abgefragt werden.

hier ein beispielhafter query, der die ganze hierarchie ausgibt:

Code: Alles auswählen

select
    concat('|_', concat(repeat('___', count(parent.idcat) - 1), catlang.name)) AS name
from 
    con_cat_tree as node,
    con_cat_tree as parent,
    con_cat_lang as catlang
where 
    node.lft between parent.lft and parent.rgt
    and node.idcat = catlang.idcat
    and catlang.idlang = 1
group by node.idcat
order by node.lft;

oder für einen breadcrumb:

Code: Alles auswählen

select
    catlang.idcat as idcat,
    catlang.name as kategorie
from 
    con_cat_tree as node,
    con_cat_tree as parent,
    con_cat_lang as catlang
where 
    node.lft between parent.lft and parent.rgt
    and node.idcat = 64
    and catlang.idcat = parent.idcat
    and catlang.idlang = 1
order by 
    parent.lft;

anmerkung: beide queries sind im beispielmandanten ausgeführt worden. der erste query wird auch sonst funktionieren, wenn eine sprache mit der id = 1 existiert. sonst müsste man das entsprechend anpassen. und beim zweiten query wird der breadcrumb der bildergalerie angezeigt. bei einer eigenen installation müsste man die idcat natürlich selbst vernünftig wählen.

ich hatte noch friktionen wegen unterschiedlicher collation (schwedisch und utf8). falls das bei euch auch auftreten sollte, müsstet ihr einfach in der tabelle con_cat_lang die collation des attributes name entsprechend anpassen (ich habe hier utf8 gewählt). und das man vorher besser einen dump der tabelle zieht muss ich euch ja nicht sagen.

das ganze läuft neben der normalen hierchiefunktion und stört diese in keiner weise. nach meiner einschätzung müsste sich das ohne weiteres einbauen lassen. die klasse, die zum download angeboten wird, macht keine inserts. diese können vorgängig normal erstellt werden. die klasse ergänzt dann lediglich die werte für lft und rgt. die aufrufe müssten nur an den betroffenen stellen vorgenommen werden. nur bei der löschung müsste man die bisherige löschung entfernen und von der klasse machen lassen.

der performance-vorteil ist gewaltig. die oben gezeigte abfrage wird bei mir beim beispielmandaten in 1 ms (!) ausgeführt. wenngleich diese form der abfrage etwas weniger intuitiv ist, ist sie in der praxis trotzdem reichlich einfacher. man muss sonst entweder unzählige joins machen oder dann sequentiell abfragen. beides ist hinsichtlich performance schlecht und auch nicht wirklich komfortabler oder einfacher.

@Dodger77 und @holger.librenz_4fb: könntet ihr das bei euch mal ausprobieren und mir sagen, was ihr davon haltet?

natürlich sind auch meinungen aller übrigen leute gefragt. ich habe dodgeer und hoger direkt angesprochen, weil ich hier das grösste interesse vermute.

bin gespannt und denke, das würde contenido wieder etwas nach vorne bringen...

gruss,
andreas

[kummer]

scheint etwas zu sein, was die welt nicht braucht...

@holger.librenz_4fb: wäre schön, wenn du dir das mal anschauen könntest.

[emergence]

scheint etwas zu sein, was die welt nicht braucht...

ernsthaft, das wundert dich ?

die welt wusste noch nie was sie braucht...
musst halt mehr werbung machen...

[kummer]

das wundert mich nun in der tat. von der unglücklichen abbildung der kategoriehierarchie sind zahlreiche module betroffen. in einer üblichen seite wird diese tabelle mindestens einmal, häufig zweimal (geteilte navi) für die navigation abgefragt. dann für die service-navi nochmal und ein weiteres mal für den breadcrumb. dann vielleicht nochmal für eine artikelliste. und das ganze mit der schlechten performance, die bei der aktuellen abbildung unvermeidlich ist.

der leistungsgewinn ist enorm und dürfte sich noch extremer auswirken bei einer seite mit einer grösseren anzahl kategorien, als das im beispielmandanten der fall ist. und das wichtigste: die anpassung wäre in null-komma-nichts vorgenommen.

[Dodger77]

Sorry, bin leider noch nicht zum Testen gekommen.

[conradius]

geht mir leider im Moment genauso. Ich teste Deine wertvolle Erweiterung bei Gelegenheit sehr gerne! Nur scheint es im Moment auch bei mir nicht die Gelegenheit zu sein...

Eine performantere Abfragemöglichkeit der Navigationsstruktur finde ich einen sehr wichtigen Beitrag.

[emergence]

@kummer
diejenigen die wirklich programmieren und den code verstehen, haben auch andere sachen zu tun... d.h einerseits ist die zeit das problem...
anderseits ist es vielen anderen vollkommen egal...

ich für meinen teil sehe es mir an, wenn ich die zeit dazu finde und erst dann kann ich was dazu sagen...

[kummer]

ich wollte niemanden stressen. ich hatte einfach die befürchtung, es würde einmal mehr einfach im sand verlaufen. ist mir schon öfter so gegangen. aber wie gesagt: ich will gar niemanden unter druck setzen und habe nächste woche ohnehin ferien.

[emergence]

bevor ich es vergesse...

(1) es wäre günstig, wenn die hierarchie in der con_tree als nested sets abgebildet werden würde (http://de.wikipedia.org/wiki/Nested_Set). das würde die komplexität bei abfragen verringern und wäre zudem noch wesentlich schneller.

es geht nur um die abfrage geschwindigkeit ?
dann können beide systeme parallel zu einander existieren..

man muss !nur! strRemakeTreeTable beibringen die rtl ltr werte zu ergänzen...

[kummer]

geanu! beide systeme können ohne weiteres nebeneinander bestehen. und sollen auch, wegen der rückwärtskompatibilität der module.