[BUG 4.9.8] PIM: Nutzung von NavMain nicht möglich

[Oldperl]

Servus,

in der plugin.xml besteht die Möglichkeit einen Eintrag in der 1. Ebene der Backend-Navigation hinzuzufügen. Dieser sollte dann, insofern es einen korrespondierenden Eintrag in der NavSub für die 2. Ebene gibt auch angezeigt werden. Dieses funktioniert aber mit den momentan für Plugins vorhandenen xml-Elementen nicht.
Grund dafür ist das Handling der Id von NavMain bei der Angabe im entsprechenden Element der NavSub. Dort muss die Id nämlich zwingend als numerische Ganzzahl angegeben werden. Erstelle ich nun aber einen entsprechenden Eintrag für MainNav, so ist mir in der plugin.xml die entsprechende Id, die bei der Installation des Plugins in die DB-Tabelle eingetragen wird, ja noch gar nicht bekannt.
Abhilfe kann hier nur eine Änderung der xml-Vorgaben bringen. So wie bei den area- und action-Elementen muss es hier eine namentliche Beziehung geben, die bei der Installation durch den PIM durch die entsprechenden Id ersetzt wird.

Gruß aus Franken

Ortwin

[frederic.schneider_4fb]

Das würde aber nur funktionieren, wenn man den Navm-Einträgen einen eigenen Namen gibt. Die Location dafür heran zu ziehen halte ich nicht für klug, weil die sich auch immer wieder ändern kann. Oder was meinst Du dazu?

[Oldperl]

Das sehe ich ähnlich. Bei NavSub ist ja wohl der Eintrag in der area-Tabelle der gemeinsame Nenner. Ich weiß nun nicht genau wie du es da umgesetzt hast mit dem Namen. Für die NavMain gibt es ja keinen Querverweis bei dem ein fester String gesetzt wird bzw. vorhanden ist. Ich denke daher man sollte hier ein zusätzliches Feld 'name' in der con_nav_main aufnehmen. Auch muss der PIM bei der Deinstallation dann darauf achten ob für die entsprechen NavMain-Id Einträge in NavSub existieren, da ja theoretisch auch weitere Plugins den entsprechenden Hauptmenüpunkt nutzen können. Damit wäre dann auch ein Master-Plugin mit ergänzenden Plugins unter einem Hauptmenüeintrag denkbar.

Leider fehlt mir da immer noch eine Art Ablaufplan für den PIM. So könnte man Beziehungen besser darstellen und entsprechende Aktionen und Reaktionen schon im Vorfeld sehen und besprechen.

Gruß aus Franken

Ortwin

[frederic.schneider_4fb]

Ich weiß nun nicht genau wie du es da umgesetzt hast mit dem Namen.

Es gibt eine Funktion, die alle existierenden Areas in ein Array schreibt und via in_array() dann jeweils vergleichen kann, ob es diese Area gibt und ersetzen kann. Das Verfahren lässt sich ja analog kopieren.

Ich denke daher man sollte hier ein zusätzliches Feld 'name' in der con_nav_main aufnehmen.

Genau, etwas anderes fällt mir auch nicht ein. Ich mache mir darüber noch einmal Gedanken. Vielleicht gibt es noch elegantere Wege. Aber das Problem ist erkannt!

[frederic.schneider_4fb]

Guten Tag,

ich habe mich heute mit der Anregung auseinandergesetzt. Die Tabelle "nav_main" erhält zukünftig eine zusätzliche Spalte "name". Bei einem Upgrade auf die neue Version werden die Standard-Einträge in der Tabelle "nav_main" auch entsprechend ergänzt.

Allerdings bin ich auf folgendes Problem gestoßen:
Wenn wir, statt bislang ids, beim Attribut "navm" in den Xml-Dateien nun Namen erwarten, dann bekommen wir ein Problem mit alten Plugins. Ich habe dann versucht einen Prozess zu entwickeln, der unterscheidet, ob man eine Id im Attribut "navm" angegeben hat, oder einen String. Allerdings funktioniert das nicht zuverlässig in allen Fällen. Eine andere Option wäre, das Attribut "navm" als Integer beizubehalten und ein neues Attribut hinzuzufügen, das dann mit den Namen arbeitet. Diese Lösung wäre einfacher umzusetzen, ist aber auch nicht sonderlich "schön".

Wie seht Ihr das? Habt Ihr noch andere Ideen, auf die ich schlicht nicht gekommen bin?

[Oldperl]

Mahlzeit,

IMO geht nur die Lösung mit einem zusätzlichen Feld. Sonst ändert sich für 'navm' ja nicht nur der Datentyp sondern auch der Bezug. Das ist kaum zu händeln damit es abwärtskompatibel bleibt. So bleibt entweder ein Schnitt ab einer bestimmten Version, oder man wechselt auf neue Attribute.
Daher wäre meine Empfehlung neue sprechende Parameter wie 'navMainName' und 'navMainId' zusätzlich zu nehmen, und die Attribute in der Reihenfolge Name, Id, navm abzuarbeiten.

Gruß aus Franken

Ortwin

[frederic.schneider_4fb]

Danke für Deine Meinung. Ich sammel noch bis Dienstagabend gerne weitere Meinungen, Ideen und setze es dann um. Stand jetzt würde ich die von Dir genannte Richtung wählen

[frederic.schneider_4fb]

Ich habe eine Lösung gefunden, es beim navm-Tag zu bleiben inklusive Rückwärtskompatibilität. Man kann "navm" also sowohl mit einer Id als auch den Namen angeben.

[frederic.schneider_4fb]

Für Details:
http://forum.contenido.org/viewtopic.php?f=91&t=36596