CONTENIDO Forum

@rbi: ich frage mich ein bisschen, welchen input 4fb denn gerne sehen würde. den kategorieproblem-thread zu sperren, nachdem eine lösung aufgezeigt worden ist, ist nicht die feine englische art. offenbar liest du den inhalt gar nicht. anyway, immerhin zeigt es mir auf, dass ich nicht ganz falsch liege, wenn ich die versuche eben eingestellt habe, einen beitrag zur weiterentwicklung von contenido zu leisten. gefragt ist das nämlich offenbar nicht (oder einfach nur von ausgewählten).

nur so als info. zurzeit werden für die verschiebung 7 abfragen abgesetzt und zahlreiche prüfungen auf php-ebene durchgeführt. nötig wäre 1 query und keine prüfungen mit php. es geht dabei jetzt nicht primär um leistung, sondern um die freiheitsgrade und damit um die fehlerwahrscheinlichkeit.

bei der verschiebung eines baumes (oder astes) werden 8 selektions- und aktualisierungsabfragen ausgeführt mit entsprechenden freiheitsgraden aufgrund der eingeführten logik, die in php abgehandelt wird (und die aktuell offenbar fehlerhaft ist). notwendig wären allenfalls 2 abfragen mit entsprechend höherer sicherheit. die tabelle con_cat_art weist eine transitive abhängigkeit auf, die man auflösen könnte. der einzige verbleibende wert in der tabelle (level) liesse sich zwar aus der unterordnung ableiten, schmerzt allerdings nicht. aber man könnte diesen gleich in die con_cat integrieren. dann müsste man bloss im rahmen der verschiebung einer kategorie das merkmal level mit der diferenz, die aufgrund der verschiebung zu erwarten ist addieren. dazu wäre eine weitere abfrage erforderlich.

auch ohne vertiefte fehlersuche lässt sich also ein fehler beheben, indem einfach die komplexität auf das notwendige mass verringert wird. wenn 4fb das projekt überhaupt noch am herzen liegt, müsste man sowas mindestens prüfen.

da gehe ich absolut konform mit andreas.
es gibt einiges absolut sinnlos programmiertes, gerade in der kategorienverwaltung, sorry aber dem ist so.

ich möchte hierzu ein von einem nutzer angemerktes "problem" (kein bug, sondern eher falsches handling des redakteurs, resp. sinnlose programmierung in der kategorienverwaltung) schildern
-> Wieso wird einer kategorie, die umgehängt wird, die parentid bereits VOR dem umhängen weggenommen?
http://forum.contenido.org/viewtopic.php?f=62&t=23965 also mal ehrlich:
- 1. muss die seite nicht neu aufgerufen werden um den neuen status anzuzeigen, wozu gibt es jquery zum austausch von grafiken, etc.
- 2. muss man der kategorie nicht die parent entziehen, damit man sie umhängen kann.
Folge: schneller, performanter und vor allem vom handling her sicherer, da sowohl bei session-timeout als auch falscher behandlung, durch NICHT auswahl der neuen platzierung die kategorie noch immer vorhanden bleibt und eben nicht einfach verschwunden ist.

Also ich habe mir nun mal die hier geposteten Codeverbesserungen per Copy&Paste schnell in ner aktuellen 4.8.12 eingebunden. Aber irgendwie kommt jetzt nur noch "Illegal Call" wenn ich die Kategorien bearbeiten will.
Hab ich nun was falsch gemacht oder muss man bei eurem geposteten Code noch was besonders beachten?
Vielen Dank für eure Hilfe.

Gruß aus Franken

Ortwin

Sorry, dass ich jetzt zur späten Stunde "aufwache", aber zu einer Sache wollte ich als "Datenbänkerin" meinen Senf geben. Andreas schrieb im anderen Thread:

normalisierung ist ein grundprinzip der relationalen datenbank. mysql ist eine relationale datenbank. und das erd ist im bereich der kategorien mehrfach-redundant.

Das Problem bei Contenido ist, dass da, wie eigentlich (leider fast) überall üblich ein Schritt in der DB-Entwicklung übersprungen wurde, nämlich das ERD überhaupt. Ich kenne die Entstehungsgeschichte nicht, aber es gab am Anfang kein ERD sondern eine Menge von Tabellen. Irgendwann, um wenigstens etwas Übersicht reinzubringen, hat Snoopy (ich weiß nicht mehr, ob alleine, oder ob noch jemand beteiligt war) ein ERD aus den Tabellen erstellt bzw. es versucht. Es konnte nicht gut gehen, denn wenn das ERD richtig ist, dann SIND die Tabellen in der 3. NF und es muss nichts normalisiert werden. Die Normalisierung braucht man nur dann, wenn man, so wie im vorliegenden Fall, die Tabellen schon hat.

Man hat aber schon bei Snoopys ERD gesehen, dass es nicht so leicht zu entknoten ist, und bei den neueren Versionen (nach 4.4.x) sind neue Tabellen dazu gekommen, die die Sache nicht vereinfachen.

Auch wenn normalisierte Tabellen natürlich wünschenswert sind: Man kann nicht "einfach so" sich hinsetzen und die Tabellen normalisieren, weil ich fürchte, dass zu viele Projekte dranhängen, wo irgendwas wahrscheinlich dazwischenfunken würde. Und die Normalisierung kann aus diesem Grund wohl auch nur jemand von 4fb machen, weil die am ehesten wissen sollten, welche Tabellen problematisch sein könnten. Aber wer hat da schon den Überblick?

@Ortwin:

Oldperl hat geschrieben:muss man bei eurem geposteten Code noch was besonders beachten

Auch wenn ich Andreas recht gegeben habe ist es nicht "mein" oder "unser" Code.
Und wie Frau Halchteranerin bereits angemerkt hat: Diese Problematik besteht schon lange, und ich bin ja auch schon lange dabei.

Halchteranerin hat geschrieben:Normalisierung kann aus diesem Grund wohl auch nur jemand von 4fb machen, weil die am ehesten wissen sollten, welche Tabellen problematisch sein könnten. Aber wer hat da schon den Überblick

Da möchte ich wiedersprechen, denn auch andere OS-Projekte bekommen das gebacken, das MUSS nicht 4fb machen, 4fb MUSS das lediglich in der Community ordentlich steuern. Dass wir fähige und bereitwillige Communitymitglieder haben ist unbestritten und war hier eigentlich schon immer so.
Allein der passende Umgang mit dieser Community und dem Produkt war/ist das Thema, dann ist auch der 3. NF kein großes Problem, inkl. Updates und DB-Änderungen.

Ich hätte alles notwendige und würde es auch zur Verfügung stellen, damit man das, zur Sicherheit von 4fb, auch gerne parallel laufen lassen kann. Ich brauche nur den aktuellen Stand der Entwicklung.

Oldperl hat geschrieben:Hab ich nun was falsch gemacht oder muss man bei eurem geposteten Code noch was besonders beachten?

nun, dieser code wurde nicht direkt für contenido geschrieben, sondern war als anregung gedacht. ich habe mal die funktion strMoveUpCategory entsprechend umgeschrieben (datei contenido/includes/functions.str.php):
das kannst du ja mal bei dir in einer testumgebung einbauen. das ist jetzt allerdings zunächst nur die verschiebung eine ebene nach oben. und nicht gleich in eine produktive umgebung einbauen, sondern zuerst eingehend testen.

analog funktioniert auch die verschiebung nach unten. die prüfungen, ob wir uns bereits zuoberst befinden oder zuunterst (innerhalb der gleichen ebene), bedarf keiner weiteren prüfung, da die queries kein update vornehmen, sollte das der fall sein. die con_cat_tree muss dabei nicht - wie das bisher der fall war - neu erstellt werden, da sich bei einer solchen operation das level ja nicht verändern kann.

bei der verschiebung eines astes in einem anderen ast (strMoveSubtree) kann das verfahren ebenfalls angewendet werden. der code ist freichlich nicht identisch; ich meine damit jetzt bloss das prinzip des simultanen updates mehrerer einträge (oder tabellen). und das beschreibene problem tritt eben genau dort auf. will heissen: dieser code löst das aktuelle problem nicht, da dieses ist der strMoveSubtree oder einer nachgeschalteten aktion auftritt. aber dieser code zeigt auf, wie man mit einer verringerung der komplexität das problem lösen kann.

dann zur frage, ob eine nachträglich überführung in die dritte (resp. 5.) normalform möglich ist oder nicht: sobald man anpassungen am datenmodell vornimmt, werden verschiedene teile betroffen sein. ich würde deshalb auch nicht dafür plädieren, gleich alles über den haufen zu schmeissen. was jedoch ohne weiteres zu machen ist, ist folgendes:

• bei abfragen der navigation auf die preid verzichten (diese information ist redundant)
• sobald keine stellen mehr vorhanden sind, welche die preid verwenden, kann diese einfach entfernt und die verschiebeoperationen entsprechend vereinfacht werden.
• das level in der con_cat_tree ist ebenfalls redundant und könnte gleich behandelt werden. dazu muss in analogie bei der abfrage das level aus der unterordnung abgeleitet werden. sobald das vorgenommen ist, kann die tabelle sowie die für die erstellung der tabelle vorgesehen funktionen gelöscht werden.
• zur weiteren verbesserung kann die tabelle con_cat um die merkmale lft und rgt ergänzt werden (für die bildung verschachtelter mengen) und die erforderlichen aktualisierungsabfragen in den entsprechenden funktionen ergänzt werden. auch hier gilt: sobald die abfragen, die vorgenommen werden, alle nur noch die lft und rgt für die bildung des kategoriebaumes verwenden, kann dann auch die postid entfernt werden.

kurz gesagt: es ist durchaus möglich, eine sanfte überführung in ein normalisiertes datenmodell vorzunehmen. es muss nicht alles in einem schritt erfolgen. was jedoch zwingend erforderlich ist: die entwickler (wenn es denn solche gibt), insbesondere die entwickler von modulen müssen auf die empfohlene variante aufmerksam gemacht werden. sonst bleibt das rückwärtskompatiblitätsproblem ewig bestehen. der beste weg dazu, ist eine - allerdings gute und leistungsfähige - API für den kategorienzugriff. wenn diese besteht und leistungsfähig ist, können die einzelnen schritte vorgenommen werden.

ich möchte mich nicht immer des klagens bezichtigen lassen. es sind auch nicht einfach klagen ohne jeden grund. es ist keine entwicklung mehr zu erkennen. und schlimmer noch, es gibt eben auch keine konsolidierung und kein bemühen, die komplexität zu reduzieren. es ist eher das gegenteil der fall. mit jeder anpassung wird der code noch etwas komplexer (und das ist beileibe keine positive qualität). ich sage an dieser stelle wieder, was ich schon des öfteren gesagt habe: offenbar wird nichts in den code integriert, dass nicht aus der richtigen quelle stammt. was auch immer der grund dafür ist, schädlich ist es alleweil. kann es sein, dass es damit zu tun hat, dass in jeder einzelnen datei ein copyright-hinweis von 4fb zu finden ist? denn dieser dürfte mindestens nicht alleine 4fb obliegen, wenn entwickler beteiligt sind, die nicht bei 4fb angestellt sind. und zwar unabhängig davon, wie die lizenz ansonsten aussieht. das urheberrecht ist unveräusserlich und liegt wie der name sagt beim urheber, sofern dieser nicht bei 4fb angestellt ist. und ohne explizite übertragung der nutzungsrechte ergibt sich für 4fb eben kein copyright. deshalb habe ich mir erlaubt, in die funktion den in diesem fall zutreffenden urheberhinweis zu integrieren (gnu/gpl gilt uneingeschränkt).

idea-tec hat geschrieben:Da möchte ich wiedersprechen, denn auch andere OS-Projekte bekommen das gebacken, das MUSS nicht 4fb machen, 4fb MUSS das lediglich in der Community ordentlich steuern. Dass wir fähige und bereitwillige Communitymitglieder haben ist unbestritten und war hier eigentlich schon immer so.
Allein der passende Umgang mit dieser Community und dem Produkt war/ist das Thema, dann ist auch der 3. NF kein großes Problem, inkl. Updates und DB-Änderungen.

So meinte ich das eigentlich nicht. "Ein paar" (nun ja, ich glaube mittlerweile sind schon über 80, oder?) Tabellen zu normalisieren dürfte noch machbar sein, aber nur 4fb weiß, was alles dran hängt, Module und sonstige Erweiterungen, die dann nicht mehr einfach so funktionieren würden. Und es muss natürlich auch sichergestellt sein, dass so etwas von 4fb übernommen wird wenn es jemand anders macht, sonst ist die Arbeit für die Füße.

Halchteranerin hat geschrieben:

idea-tec hat geschrieben:Und es muss natürlich auch sichergestellt sein, dass so etwas von 4fb übernommen wird wenn es jemand anders macht, sonst ist die Arbeit für die Füße.

zum glück stellt das auch mal jemand anderes fest. danke an dieser stelle.

Mal ganz ehrlich:
Es ist ein OpenSource-Projekt, und die paar Module aus dem Beispielmandanten ans Laufen zu bekommen ist ja eher ein Scherz als eine Aufgabem wenn vorher der rest sauber erledigt war.
und nunja, die ganzen module aus der community, die für die 4.4 lafen auch noch seltenst in der 4.8, oder?

im sinne das validät und zukuntsaussichten würde ich dazu plädieren, dass man das in der community mal eben umsetzt, nen cut macht, und gut ist.
das hat die komplette .net-gemeinde gemacht, als die ihren access-scheiß gekillt haben, das haben viele andere os-projekte gemacht, und einige davon prüfen inzwischen schon ob php6 auf der ausführenden kiste läuft.

wenn es hier keiner macht, mach ich es alleine für mich. so kann ich das produkt auf keinen fall brauchen, empfehlen oder produktiv einsetzen.

Hey Karsten, ich rede nicht von den paar Modulen, die mitgeliefert werden, und auch nicht von denen, die hier im Forum rumschwirren, sondern von denen (und von Erweiterungen), die 4fb an die Kunden verkaufen, oder glaubst du, die Module vom Beispielmandant will jemand kaufen? Ich rede auch davon, was gemacht werden soll, wenn es bei Contenido bleibt, sprich, was auch in künftigen Versionen Einzug findet, und nicht wenn sich einige Leute zusammentun und einen Split-Off, was sie dann weiter entwickeln, zustande bringen.

Bzgl. der Rückwärtskompatibilität: es gibt zahlreiche Navigationsmodule hier, welche die con_cat_tree verwenden. Und die benötigen die dann für die Ebene UND die Reihenfolge der Kategorien.

Naja, die Interessen der 4fb sind mir da relativ egal, da denen meine auch am Hintern vorbei gehen. Das ist die Natur der Geschichte bei OpenSource.
Und nunja, ich verkaufe meine Module IMMER nur versionsbezogen (egal welches CM-System zugrunde liegt). D.h. haben die 4fb oder diverse CommunityMitglieder da andere Verträge, dann haben sie was falsch gemacht.

@Dodger:
Irgendwann ist bei jeder Software der Punkt erreicht wo man einen Cut machen MUSS.
Stillstand ist Rückschritt und die Nichtbeachtung technischer Weiterentwicklungen und dem beharren auf schlechtem Coding ist der Exodus.

Dodger77 hat geschrieben: Und die benötigen die dann für die Ebene UND die Reihenfolge der Kategorien.

hallo ingo

kannst du mir erklären, wie du diese informationen für die reihenfolge brauchen kannst?:
die idtree wird, soweit ich es sehen kann, nirgends sonst in der datenbank verwendet. was bedeutet, dass dieser schlüssel als informationsträger entfällt. dann bleibt noch das merkmal level, das jedoch mit der reihenfolge nichts zu tun hat. aus meiner sicht, dürfte es diese tabelle gar nicht geben. das level auch nicht, da es eine abhängigkeit der unterordnung darstellt. wenn man es irgendwo benötigt, könnte man es auch in die con_cat legen.

die rückwärtskompatiblität wird sich nicht dauerhaft erhalten lassen. mit jeder version gibt es im übrigen module, die dann nicht mehr funktionieren. aber es gibt ja auch ersatz.

folgende abfrage gibt null:
die idcat ist also eindeutig und ein weiterer schlüssel deshalb ohne informationswert. der einzig verbleibende wert ist das level.

Es sollte nur ein Hinweis darauf sein, dass dies aktuell so verwendet wird in verschiedenen Modulen und damit wahrscheinlich in einer Menge an Installationen. Wenn man sich da zu einer Änderung entschließt (was ich absolut sinnvoll finde), muss man sich damit aber halt im Klaren sein, was das für Folgen für die Installationen hat. Um nicht mehr und nicht weniger ging es mir.

kummer hat geschrieben:kannst du mir erklären, wie du diese informationen für die reihenfolge brauchen kannst?:

Ich kann die gar nicht brauchen. Aber diverse Module tun dies halt ("ORDER BY idtree"), ob das jetzt sinnvoll und notwendig sein mag oder nicht.