CoreData+Bindings / NSBundles
PoM
Membre
Salut à tous,
J'ai un petit soucis de conception de l' architecture de mon appli.
Voici le tableau très simplifié de celle-ci:
Jusque là , rien de bien compliqué.
Mon problème est que je souhaite binder des éléments présents dans les XIB de mes Bundles sur le modèle présent dans mon appli principale.
Vu que mes bundles, par définition, sont des projets créés séparément, et buildés séparément, je ne vois pas comment faire ça.
Dois-je gérer tout en KVC dans mes bundles et notifier mon appli principale qu'il y a eu un changement (c'est un peu dégueu je trouve) ?
Peut on partager un modèle ou plus précisément un Context entre l'appli et les bundles ?
... ?
Peut etre que je me suis mal orienté dès le départ et que les bundles ne sont strictement pas fait pour ça.
Dans ce cas là , vers quelle solution puis-je me tourner ?
Merci de votre aide.
PoM
J'ai un petit soucis de conception de l' architecture de mon appli.
Voici le tableau très simplifié de celle-ci:
- j'ai une appli avec mon modèle CoreData complet.
- cette appli load des Bundle cocoa et les instancie au démarrage.
- Lorque je clique sur tel ou tel bouton, ça retrouve l'instance voulue et appelle une méthode qui va lancer la fenetre du Bundle et les quelques méthodes "métier" du Bundle
Jusque là , rien de bien compliqué.
Mon problème est que je souhaite binder des éléments présents dans les XIB de mes Bundles sur le modèle présent dans mon appli principale.
Vu que mes bundles, par définition, sont des projets créés séparément, et buildés séparément, je ne vois pas comment faire ça.
Dois-je gérer tout en KVC dans mes bundles et notifier mon appli principale qu'il y a eu un changement (c'est un peu dégueu je trouve) ?
Peut on partager un modèle ou plus précisément un Context entre l'appli et les bundles ?
... ?
Peut etre que je me suis mal orienté dès le départ et que les bundles ne sont strictement pas fait pour ça.
Dans ce cas là , vers quelle solution puis-je me tourner ?
Merci de votre aide.
PoM
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Ceci dit, c'est faisable.
Situation habituelle
Dans le cas d'une appli Core Data multi-documents, donc basée sur NSPersistentDocument, on fixe le binding ManagedObjectContext des NSObjectControllers à [File's Owner].document.managedObjectContext
-> [File's Owner] est un NSWindowController. Sa propriété document pointe sur son NSPersistentDocument parent, qui contrôle le MOC.
Avec un bundle
Le fait que tu charges des bundles ne modifie pas beaucoup la donne. Mais il va falloir trouver un chemin vers le MOC du document pour le binding des NSObjectControllers. Par exemple, si c'est ta sous-classe de NSPersistentDocument qui charge le bundle, le binding sera simplement [File's Owner].managedObjectContext.
Je vais regarder cette solution de plus prêt.
Cela dit, ta prémière réaction me fait dire que c'est peut être quelque chose d'inutile.
C'est ça aussi que je voudrais savoir.
J'ai décidé de faire une archi de type "plugin" (avec les bundles cocoa) afin d'alléger l'appli principale et surtout que tout ne soit pas "loadé" au démarrage.
Peut être que je me fais de fausses idées.
Je t'avoue que si ce n'est pas le cas, faire une appli avec tous mes composants dedans m'arrangerait pas mal en terme de facilité de programmation mais par contre retirerait le coté "découverte de nouveaux aspects de l'objective-C / Cocoa".
Mais si ce n'est pas adapté, alors je laisse tomber.
Un avis sur la question ?
Merci
Utiliser les Bundles se justifie pleinement si le code correspondant à tes plug-ins est très gros ou si tu veux permettre à des développeurs tiers de développer des plug-ins. Autrement, c'est à éviter puisque c'est plus compliqué.
Par exemple, quand on code une appli iPhone, en général on prend l'habitude (qu'on n'a pas forcément quand on code pour OSX car on n'a pas les mêmes contraintes de mémoire à penser) de séparer chaque écran iPhone dans un fichier XIB séparé. Comme ça seul le XIB principal (MainWindow.xib, contenant le ViewController racine de l'appli et un lien vers le modèle ou des trucs comme ça) est chargé, et si l'on a besoin d'afficher un autre écran, on prévoit un autre XIB pour ça, et on ne charge ce XIB que quand c'est nécessaire.
Pour charger un XIB (qui est dans ton bundle principal de ton appli) tu utilises [tt][[NSBundle mainBundle] loadNibNamed:... owner:... options:...][/tt] qui te permettent d'indiquer le XIB à charger et quel objet en sera le File's Owner.
Bon dans le cas de l'iPhone y'a les classes UIViewControllers et sa méthode "initWithNibName:... bundle:..." qui facilitent la chose et rendent ça plus naturel, mais au final ça fait la même chose ça finit par appeler la méthode [tt]loadNibNamed:owner:options:[/tt] aussi même si certains ne le réalisent même pas)
Du coup tu peux mettre tous des XIB dans le même bundle, pas besoin d'avoir 36 bundles différents servant de "plugins". Une architecture en plugins n'est à mon sens intéressante que pour avoir un aspect modulaire, pour pouvoir rajouter à la volée des plugins donc des fonctionnalités à ton application (par exemple pour une application de lecture de vidéo, pouvoir rajouter des codecs pour supporter plus de formats vidéos, ce genre d'usage). Si ton application devra de toute façon avoir tes plugins de présents pour fonctionner sinon elle ne marchera pas, et que tu n'as pas l'intention de permettre à des développeurs tiers d'ajouter des fonctionnalités par plugins par la suite à ton appli, ça me semble inutile de monter une architecture comme ça.
En fait, je ne compte effectivement pas faire appel à des développeurs tiers.
Le fait est que sur cette appli, les composants n'ont pas grand chose à voir entre eux, c'est plus une "suite" d'appli regroupées en une seule à la Mozilla (browser, news, mails ...) ou Coda (SSH, éditeur de texte, browser de docs ...), si vous voulez.
Je suis susceptible de rajouter un composant en fonction de l'utilisation ... ou pas.
Rien n'est fixé à l'heure actuelle, bien que j'ai déjà la liste très précise des composants dont j'ai besoin dès le départ.
C'est aussi pour ça que je me suis orienté vers une archi de type "plugin", c'est que ça peut éventuellement évoluer ! Mais c'est peut être une erreur.
De fait, je pense que je vais zapper le coté Bundle dès maintenant car c'est vrai que c'est une archi bien complexe pour ce que je veux réaliser.
En tout cas, merci infiniment pour vos aides et conseils précieux.
Je publierai bien entendu ici ladite appli une fois qu'elle sera terminée.
A bientôt.