On 11/03/2014 04:53 PM, bernd wilke wrote: > Am 03.11.14 16:08, schrieb g4-l...@tonarchiv.ch: >> Hallo Liste, >> >> ich versuche folgendes Konstrukt umzusetzen: >> >> Das Mutterobjekt "Konzern" hat mehrere Unterobjekte "Standorte". Diese >> Standorte wiederum habe Abteilungen. >> Soweit so gut. >> >> Nun gibt es aber auch Abteilungen, die direkt dem Konzern untergeordnet >> sind. Jetzt könnte ich natürlich einfach der Klasse "Konzern" auch eine >> Relation "Abteilung" hinzu fügen. >> Ich fände es aber hübscher, wenn alle Abteilungen auf der gleichen Ebene >> eingebunden sind. Daher würde ich einfach einen "Dummy-Standort" hinzu >> fügen, der die Abteilungen des Konzerns vereint. >> Spricht etwas dagegen, diesem Standort eine negative UID zu geben, damit >> er dadurch von den normalen Standorten unterscheidet werden kann? Ist >> das überhaupt möglich? > > hm. implizite Sonderregeln sind immer eine Gefahr. > > wenn ich mir aktuell ansehe was für Probleme es mit Flux,Gridelements > gibt: negative colPos-Werte für CEs wenn sie in einem anderen Element > eingebunden sind (IRRE). und auf einmal verrutschen Elmeente aus der > hauptspalte (colPos=0) ins Nirwana (colPos = -1 ohne Parent) > > oder vor 15 Jahren mit Geburtsjahr = '99' für unbenutzt. Das war noch > viel schlimmer als Y2K. > >> Die andere Variante wäre wohl einfach eine boolsche Property >> "isKonzern" ... > > klingt viel vernünftiger. > oder ("do not display division") > > bernd Hi Bernd,
alles klar. Das 99 ne noch schlechtere Idee ist, war mir gleich klar. Eigentlich wäre ja die UID 0 für den Zweck prädestiniert, aber das führt bestimmt zu anderen Problemen... Was ist mit "do not display division" gemeint? Ist das auch ein Flag? Grüße, Till _______________________________________________ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german