CoreData - NSTreeController

Siehe die beiden Bilder im Anhang. Wenn du fragen hast, einfach antworten. Ich bin noch ne Weile hier.

Na, aber genau das _will_ ich doch gar nicht, weil ich eben nicht weiß, ob das Objekt später ein Root-Objekt sein soll oder nicht!

Wenn du einen Graphen hast, dann willst du das. Sonst wäre es kein Graph. Du kannst mit CD natürllikch DB-Funktionalität abbilden. Dazu ist aber CD nicht gedacht. Daher rührt die Nerverei.

Apple macht da nichts falsch. Apple macht einfach nur etwas anderes, als du dir vorstellst. Das führt natürlich dann zur Flickschusterei, Gefummele usw -- bis man genervt ist.

Meine Idee zur CoreData-Übung war eine Art ToDo-Liste.
Da mir ein einfaches unverschachteltes ToDo-Element zu langweilig war, wollte ich es so einrichten, dass ein ToDo-Element unterschiedliche Sub-Elemente enhalten kann, aber nicht muss.

Das ist kein Problem. Du hast eine Enität "ToDoList" und die enthält die hinzugefügten Root-Elemente. Diese können, müssen aber nicht Subelemente enthalten. Der Unterschied besteht nur darin, dass du nicht alle Elemente holst und dann hinterherfrickelst, sondern die Elemente holst, die in der übergeordneten List gespeichert sind.

Mir persönlich ist einfach nicht klar, wieso unser OutlineView bzw. der TreeController (wer auch immer jetzt dafür verantwortlich ist) eben alles mehrfach anzeigt.

Jepp, das ist aber klar, siehe unten das Bild. Wenn du einfach nur hereinziehst, holst du *alle* Instanzen einer Entität. Alle bedeutet damit auch *alle* die in einer *anderen* List gespeichert sind und es bedeutet auch *alle* die bloß Subelemente sind. Du greifst wie auf eine Tabelle zu. Eine Tabelle ist aber stets flach.

Wie gesagt: Was du da machst ist ein klassisches Problem der Reflexivverknüpfungen in einer DB. Du brauchst das Problem aber gar nicht erst aufkommen zu lassen.

Die Lösung soltle damit eigentlich klar sein: Mach zwei Entitäten, eine ToDoList und eine Element. Dann verknüpft du von der ToDoList auf die Elemente, die dann nur die Roots enthalten. Innerhalb der Elemente machst du es so wie bisher.

Wenn du nun den TreeController an die ToDoList bindest, findet CD gleich die richtigen Elemente, soll heißen, nur die Root-Elemente und nur die zur passenden zu dieser ToDoList.

Prädikate sind in Datenbanken dafür erfunden worden. In CD dienen sie dazu, *innerhalb* der *bereits richtigen* Elemente welche zu filtern.

Sorry, du korrigierst schon wieder deinen anfänglichen Denkfehler von hinten herum. Das führt natürlich zur Nerverei. Ständiig muss man fummeln.

Mach es mal wie oben beschrieben.

Original von Tom9811
Sorry, du korrigierst schon wieder deinen anfänglichen Denkfehler von hinten herum. Das führt natürlich zur Nerverei. Ständiig muss man fummeln.

Falls du das auf die Delete Rule beziehst widerspreche ich dir ganz vehement!

Nichts ist nerviger als Elemente in der Subentität, die keine Väter mehr haben aber trotzdem noch drin stehen.
Denn ohne Weiteres kommt man an die nicht mehr heran.

Mit anderen Worten: Ich achte immer auf einen sinnvollen Einsatz der Löschregeln.

Auch wenn ich deine Grafiken nicht so ganz kapiert habe versuche ich trotzdem deine Variante.

Hier habe ich dann nur das Problem: Wie erkläre ich den Subelementen, dass sie Subelemente haben können?
Ich habe dafür eine transiente Relationship auf die Entität selbst gesetzt.

Da der Compiler aber immer anmerkt, dass diese Relationship keinen Inverse hat, denke ich mal, dass das nicht die sauberste Lösung ist.

Ich habe mal einen Screenie und ein Projekt angelegt. Das geht jetzt ganz ohne Code, ohne Prädikate usw. Man muss sich eben nur dem Pfad des Objekt-Graphen entlanghangeln -- so wie man das shcon immer gemacht hat:

Scheiße, zu groß
Kann mir mal jemand von euch eine echte E-Mail schicken?

Nö, das ist nur in einer DB nervig.

Für Core Data ist diie Sache von vornerein klar, weil es gleich die Objekt-Hierarchie abbildet, nicht Tabellen einer Datenbank!

Original von Tom9811
Für Core Data ist diie Sache von vornerein klar, weil es gleich die Objekt-Hierarchie abbildet, nicht Tabellen einer Datenbank!

Dann frage ich mich, wozu Apple Funktionen bereit stellt, die an sich überflüssig sind...

//edit_

Na, so ganz glaube ich dir nicht.

Ich habe mal eben ganz simpel deinen Vorschlag nachgebaut.
Neben dem NSTreeController habe ich noch zwei Fenster, eines zeigt sämtliche Instanzen aus Parents an, das Andere sämtliche Instanzen aus Children.

Wenn ich ein Parent rauswerfe, ist das Parent der zuvor zugeordneten Children 'no value'.
Die Children kleben noch immer da, werden lediglich im OutlineView nicht angezeigt. : P

Setze ich die delete rule in der Children-Relationship dagegen auf CASCADE, fliegen die Kinnings (Pänz, wie der Kölner zu sagen pflegt) raus.

lucasdevil.info/Cocoa/CDTests.zip

Die Funktion ist nicht überflüssig, sondern macht an dieser Stelle nicht das, was du erwartest.

Ich schaue mir dein Projekt nicht an. Wie es geht habe ich dir ja zugemailt. Aber oich mutmaße, dass du imemr noch am Anfangsfehler hängst.

BTW: Das waren jetzt nicht zwei Tage Nerverei, sondern 10 Minuten klicken.

Original von Tom9811
Die Funktion ist nicht überflüssig, sondern macht an dieser Stelle nicht das, was du erwartest.

Ich schaue mir dein Projekt nicht an. Wie es geht habe ich dir ja zugemailt. Aber oich mutmaße, dass du imemr noch am Anfangsfehler hängst.

1) Doch, tut sie.
2) Schade. Angst?
3) Scheinbar inklusive Build-Verzeichnis. Armes ISDN.
Dennoch vielen Dank!.
Mal sehen ob ich dich auch mit deinem Projekt darauf festnageln kann, dass du Unrecht hattest. ; )

Jip, kann ich! : P

*Schulterzuck* Ich bin es dann leid.

Es ist ja nicht mein Problem, Core Data falsch zu verstehen und dann zwei Tage lang dem Anfangsfehler hinterher zu nerven. Ich mache es derweil einfach richtig.

BTW: Nein, keine Angst. Vielmehr Kappitel 9 zur Korrektur bekommen. Vielleicht solltest du dir überlegen, ob es hier um einen Kampf und Rechtbehalten geht oder um die Sache. Wie gesagt: Mein Problem ist es nicht. Derlei Mini-Applikation klicke ich ganz entspannt in 10 Minuten zusammen.

Tom
Scheint mir ein typischer Fall von Missverständnis zu sein.

Die App ist genau das, was ich wollte!
Lediglich die Delete Rule macht genau das, was ich gesagt habe.

hanswurst
Sie haben Post!

Nein, die Delete Rule sorgt für das Aufräumen der Instanzen. Sie ist nicht dazu gedacht, Hierarchien zu reparieren.

Aber das ist jetzt müßig.

Wobei du natürlich eine Deletion Rule eingeben solltest. Das war in der Tat teilweise ein Missverständnis zwischen uns.

Sorry, mea culpa.

Gepriesen sei die Suchfunktion. Hab denselben Denkfehler doch tatsächlich schon wieder gemacht.
Daran sieht man mal wieder:
Ich habe es nie vor CoreData gemacht
Ich habe es immer noch nicht kapiert

Ich mal wieder...
Passt diesmal nicht ganz, weil ich das ohne Core Data versuche.
Aber ich habe dasselbe Problem: ich will, dass mein TreeController gefälligst mehr als eine Wurzel anzeicht.

Also statt


hätte ich gern


Nur wie?

Meine Idee, - (id)outlineView:(NSOutlineView *)outlineView child:(int)index ofItem:(id)item einfach die Kindelemente unterzujubeln schlug kläglich fehl.

[Session started at 2008-01-28 22:46:29 +0100.]
2008-01-28 22:46:29.609 cmXs[10381] *** -[NSCFArray numberOfChildren]: selector not recognized [self = 0x357480]
2008-01-28 22:46:29.610 cmXs[10381] An uncaught exception was raised
2008-01-28 22:46:29.610 cmXs[10381] *** -[NSCFArray numberOfChildren]: selector not recognized [self = 0x357480]
2008-01-28 22:46:29.611 cmXs[10381] *** Uncaught exception: <NSInvalidArgumentException> *** -[NSCFArray numberOfChildren]: selector not recognized [self = 0x357480]

cmXs has exited with status -1.

Kein Wunder, schließlich kennt das Array mit den Kindelementen die Methode 'numberOfChildren' nicht. Woher auch, reicht ja wenn das Kindelement diese kennt.

Ich weiß, dass es irgendwie gehen muss, die gewünschte Darstellung ohne den von Tom vorgeschlagenen Array-Umweg zu gehen.
Sieht man ja an Xcode.

Aber ich weiß nicht wie.
Hat da jemand nen Plan? Oder wenigstens ne Karte???