2011-10-07 4 views
2

Mon application, une application Core Data basée sur un document, passe par une seconde itération et nécessite maintenant plusieurs fenêtres pour gérer plusieurs objets de modèle. Actuellement, il gère les événements et les emplacements à travers une fenêtre et un contrôleur. La classe de document générée standard agit en tant que contrôleur pour la fenêtre principale pour le moment.Quelle est la meilleure approche pour une application Cocoa basée sur un document multi-fenêtres?

Je veux maintenant une fenêtre séparée pour la gestion des objets du modèle Emplacements. Il semble bon d'avoir un contrôleur séparé (NSWindowController) pour chaque fenêtre, mais j'ai ensuite réalisé que ces contrôleurs n'auront pas accès au contexte d'objet géré, qui est requis pour accéder aux objets du modèle.

Quelle est la meilleure approche ici?

EDIT:

J'ai suivi solution ughoavgfhw comme suit:

  • créé un nouveau XIB pour les emplacements et a ajouté un contrôleur de réseau pour charger des objets Emplacement
  • créé un contrôleur personnalisé ManageLocationsController comme une sous-classe NSWindowController
  • Fait le contrôleur personnalisé le propriétaire du fichier dans les emplacements XIB
  • cartographiés Array contexte du contrôleur de fichier propriétaire et KeyPath document.managedObjectContext

J'ouvre la fenêtre Localisation avec:

ManageLocationsController *aController = [[ManageLocationsController alloc] initWithWindowNibName:@"ManageLocations"]; 
[aController showWindow: self]; 

Cela se fait à partir EventDocument, qui est la classe par défaut générée par XCode. Lors du mappage du contrôleur de matrice, il restait un point d'exclamation noir dans le champ keyPath et lorsque j'ouvrais la fenêtre Emplacement, il lançait une exception disant "impossible d'exécuter une opération sans objet géré". De toute évidence pas bon. Qu'est-ce que je rate?

Répondre

3

L'utilisation de contrôleurs de fenêtre personnalisés est la meilleure façon de procéder. Un contrôleur de fenêtre peut ne pas avoir un accès direct au contexte d'objet géré, mais il a accès au document, ce qui est le cas. Vous pouvez y accéder par programmation en utilisant windowController.document.managedObjectContext ou à partir de liaisons avec le chemin de clé document.managedObjectContext. Si vous souhaitez simuler un accès direct au contexte d'objet géré, vous pouvez créer une propriété readonly qui le charge à partir du document.

// header 
@property (readonly) NSManagedObjectContext *managedObjectContext; 

// implementation 
- (NSManagedObjectContext *)managedObjectContext { 
    return self.document.managedObjectContext; 
} 
+ (NSSet *)keyPathsForValuesAffectingManagedObjectContext { 
    return [NSSet setWithObject:@"document.managedObjectContext"]; 
} 

La méthode keyPathsForValuesAffectingManagedObjectContext est utilisé pour indiquer la valeur clé du système d'observation que tout objet en observant la propriété managedObjectContext doit être informé des changements chaque fois que les chemins renvoie le changement.

Pour que les contrôleurs de fenêtre fonctionnent correctement, vous devez les ajouter au document en utilisant addWindowController:. Si vous créez plusieurs fenêtres lors de l'ouverture du document, vous devez remplacer makeWindowControllers dans votre méthode de document pour créer les contrôleurs de fenêtre, car ceux-ci seront appelés automatiquement au bon moment. Si vous créez des contrôleurs de fenêtres sur demande, vous pouvez les créer avec la méthode que vous voulez, assurez-vous de les ajouter au document. En ce qui concerne le petit point d'exclamation noir dans IB, vous devrez juste ignorer cela.La propriété document de NSWindowController est définie avec le type NSDocument, mais la propriété managedObjectContext est définie par la sous-classe NSPersistentDocument. IB vous avertit que la propriété n'est peut-être pas là, mais vous savez que ce sera le cas, vous pouvez simplement l'ignorer.

+0

Un grand merci. J'ai édité les questions avec les résultats selon votre réponse. – Roger

+0

@Roger Désolé, j'ai oublié d'ajouter des détails sur l'utilisation de contrôleurs de fenêtre personnalisés avec NSDocument. Je vais ajouter ça maintenant. – ughoavgfhw

+0

Merci pour cela. Cela a aidé bien que maintenant je reçois "cette classe n'est pas la valeur clé codage-conforme pour les exceptions clés managedObjectController". Je soupçonne que cela a à voir avec la méthode keyPathsForValuesAffectingManagedObjectContext. Dois-je implémenter cette méthode dans ma classe de contrôleur personnalisé? – Roger

Questions connexes