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

Antwort per Email an