Hallo,
ich arbeite momentan an der zweiten Version meiner Lernsoftware. Ganz kurz: Man kann Karteikästen anlegen und darin Karteikarten verwalten.
Es gibt mehrere Karteikastentypen - ähnlich wie in iTunes gibt es einen Karteikasten (den Library Karteikasten), der alle Karteikarten enthält. Es gibt intelligente Karteikästen (ähnlich den intelligenten Wiedergabelisten), es gibt Karteikasten Ordner, die wieder Karteikästen enthalten können.
Nun stehe ich vor einem Problem. Jeder Karteikästen enthält viele Karteikarten. Einige Karteikästen ermitteln die in ihnen befindlichen Karteikarten sehr dynamisch - z.B. die intelligenten Karteikästen, die Karteikarten nach definierten "Regeln" finden.
Ich habe dazu eine abstrakte Entität "AbstractDeck" (also abstrakter Karteikasten) und einige konkrete Entitäten, die von dieser Entität ableiten: "LibraryDeck" (der Library Karteikasten), "SmartDeck" (intelligenter Karteikasten), "GenericDeck" (ein normaler Karteikasten), ...
[Blockierte Grafik: http://christian-kienle.de/model.jpg]
Wie gesagt hat jeder Karteikasten - egal welchen Typs viele Karteikarten. Es bietet sich also eine to-many Beziehung an. Super - mit diesem Model hat das auch ganz gut geklappt - allerdings:
Die Karteikarten, die ein intelligenter Karteikasten enthält will ich ja nicht abspeichern. Ich bräuchte für ihn also eine transiente Beziehung. Ebenso für den Library Karteikasten. Das ist nun aber das Problem. Eine to-many Beziehung ist entweder "transient" oder nicht. Sie kann nicht in einer abgeleiteten Entität transient sein und in einer anderen abgeleiteten nicht.
Mein erste Gedanke war dann die Card Entität ebenfalls abstrakt zu halten. Die Card Entität wird abstrakt und zwei neue Entitäten leiten von ihr ab:
TransientCard (eine Karte, die nicht gespeichert wird) und StoredCard (eine Karte, die gspeichert wird).
Zusätzlich dazu habe ich die "cards" Beziehung von "AbstractDeck" auf transient gestellt und die Zielentität von "Card" auf "TransientCard" gestellt. Die "deck" Beziehung von "TransientCard" ist ebenfalls transient.
GenericDeck hat eine neue Beziehung "storedCard" erhalten. die auf "StoredCard" verweist.
[Blockierte Grafik: http://christian-kienle.de/model2.jpg]
Nun kommt der Trick:
Das UI sieht so aus: Links wie in iTunes eine Liste mit den Karteikästen. Rechts eine Tabelle mit den in dem ausgewähltem Karteikasten enthaltenen Karteikarten. Gebunden wird immer an "cards". Im AbstractDeck Subclass von GenericDeck überschreibe ich die setCards: und cards: Accessors:
setCards: reicht die Karten weiter an "storedCards", sodass diese gepseichert werden.
cards gibt einfach das, was in storedCards gespeichert ist zurück.
Bisher klappt das so ganz gut - nur frage ich mich, ob ich das nicht zu umständlich mache.
ich arbeite momentan an der zweiten Version meiner Lernsoftware. Ganz kurz: Man kann Karteikästen anlegen und darin Karteikarten verwalten.
Es gibt mehrere Karteikastentypen - ähnlich wie in iTunes gibt es einen Karteikasten (den Library Karteikasten), der alle Karteikarten enthält. Es gibt intelligente Karteikästen (ähnlich den intelligenten Wiedergabelisten), es gibt Karteikasten Ordner, die wieder Karteikästen enthalten können.
Nun stehe ich vor einem Problem. Jeder Karteikästen enthält viele Karteikarten. Einige Karteikästen ermitteln die in ihnen befindlichen Karteikarten sehr dynamisch - z.B. die intelligenten Karteikästen, die Karteikarten nach definierten "Regeln" finden.
Ich habe dazu eine abstrakte Entität "AbstractDeck" (also abstrakter Karteikasten) und einige konkrete Entitäten, die von dieser Entität ableiten: "LibraryDeck" (der Library Karteikasten), "SmartDeck" (intelligenter Karteikasten), "GenericDeck" (ein normaler Karteikasten), ...
[Blockierte Grafik: http://christian-kienle.de/model.jpg]
Wie gesagt hat jeder Karteikasten - egal welchen Typs viele Karteikarten. Es bietet sich also eine to-many Beziehung an. Super - mit diesem Model hat das auch ganz gut geklappt - allerdings:
Die Karteikarten, die ein intelligenter Karteikasten enthält will ich ja nicht abspeichern. Ich bräuchte für ihn also eine transiente Beziehung. Ebenso für den Library Karteikasten. Das ist nun aber das Problem. Eine to-many Beziehung ist entweder "transient" oder nicht. Sie kann nicht in einer abgeleiteten Entität transient sein und in einer anderen abgeleiteten nicht.
Mein erste Gedanke war dann die Card Entität ebenfalls abstrakt zu halten. Die Card Entität wird abstrakt und zwei neue Entitäten leiten von ihr ab:
TransientCard (eine Karte, die nicht gespeichert wird) und StoredCard (eine Karte, die gspeichert wird).
Zusätzlich dazu habe ich die "cards" Beziehung von "AbstractDeck" auf transient gestellt und die Zielentität von "Card" auf "TransientCard" gestellt. Die "deck" Beziehung von "TransientCard" ist ebenfalls transient.
GenericDeck hat eine neue Beziehung "storedCard" erhalten. die auf "StoredCard" verweist.
[Blockierte Grafik: http://christian-kienle.de/model2.jpg]
Nun kommt der Trick:
Das UI sieht so aus: Links wie in iTunes eine Liste mit den Karteikästen. Rechts eine Tabelle mit den in dem ausgewähltem Karteikasten enthaltenen Karteikarten. Gebunden wird immer an "cards". Im AbstractDeck Subclass von GenericDeck überschreibe ich die setCards: und cards: Accessors:
setCards: reicht die Karten weiter an "storedCards", sodass diese gepseichert werden.
cards gibt einfach das, was in storedCards gespeichert ist zurück.
Bisher klappt das so ganz gut - nur frage ich mich, ob ich das nicht zu umständlich mache.
Die Objective-Cloud ist fertig wenn sie fertig ist. Beta heißt Beta.
Objective-C und Cocoa Band 2: Fortgeschrittene
Cocoa/Objective-C Seminare von [co coa:ding].
Objective-C und Cocoa Band 2: Fortgeschrittene
Cocoa/Objective-C Seminare von [co coa:ding].