Interface multi-nib dans une seule fenêtre

regattaregatta Membre
j'ai besoin de vos lumières pour mon problème !

Mon application cocoa est du type "Application cocoa simple" avec de multiples fichiers nib.
Chaque fichier nib correspond à  une fenêtre et une classe NSDocument et NSWindowController (MVC).
Les données sont stockées dans une base (sqlite et/ou mysql).
Suivant les données à  gérer, un fichier nib est chargé, et la fenêtre apparaà®t à  l'écran.

Mon souhait est d'éviter ces multiples fenêtres et de centraliser dans une seule fenêtre le contenu de la fenêtre correspondant aux données à  gérer (bouton de choix des données à  gérer + cadre d'affichage/gestion des données).

Je suis parti sur une solution qui me paraà®t fonctionner mais qui semble folle :(

Une solution propre dans le cadre Cocoa-MVC  :why?:

Réponses

  • Eddy58Eddy58 Membre
    20:40 modifié #2
    Je ne sais pas combien tu as de fichier nibs, mais ça doit t'en faire des fenêtres. ;)
    Je serais plutôt parti d'une appli "Document Based", avec une seule sous-classe NSDocument, et dans le fichier nib associé, il doit bien être possible de faire tenir tout les éléments, quitte à  mettre des onglets pour accéder aux différentes catégories de données.
  • août 2006 modifié #3
    Je pense que ton problème vient d'une confusion entre objets et sources des objets. Un nib c'est qu'une manière commode de stocker des objets de type "interface graphique", rien de plus (et commode pour les créer grâce à  Interface Builder). Je suppose que si tu es parti sur le document, c'est que tu as du penser que c'était la façon la plus simple de gérer les multi-nibs car NSDocument charge automatiquement un nib, mais rien ne t'empêche de charger tes nibs à  la main, au cas par cas.

    Maitenant, tu n'es pas obligé de stocker des fenêtres dans tes nibs, tu peux aussi stocker des vues, et une fois que tu as ton objet vue, tu en fais ce que tu veux: créer un nouvel onglet dans une tabView, remplacer la contentView d'une fenêtre, créer une nouvelle fenêtre en le mettant comme contentView,...

    Fais une recherche sur le File's owner et la méthode [tt]loadNibNamed:owner:[/tt] (NSBundle) sur ce forum, tu auras déjà  sûrement beaucoup de pistes.
  • regattaregatta Membre
    20:40 modifié #4
    Merci pour vos réponses.
    Voici quelques précisions :

    Je ne sais pas combien tu as de fichier nibs, mais ça doit t'en faire des fenêtres

    En fait, 4 fenêtres avec des onglets sur chaque fenêtre (autant que de tables principales dans la base).

    mais rien ne t'empêche de charger tes nibs à  la main, au cas par cas.

    C'est effectivement ce que je fais.

    Maitenant, tu n'es pas obligé de stocker des fenêtres dans tes nibs, tu peux aussi stocker des vues, et une fois que tu as ton objet vue, tu en fais ce que tu veux: créer un nouvel onglet dans une tabView, remplacer la contentView d'une fenêtre, créer une nouvelle fenêtre en le mettant comme contentView,...

    C'est la piste sur laquelle je suis parti  :o

    La différence est que sur ma vue principale, j'ai des boutons pour choisir la vue à  afficher et que la vue s'affiche dans une CustomView en utilisant AddSubview et RemoveSubview.
    Pour cela, j'ai créé une vue autour du contenu de chaque fenêtre (de chaque nib) à  afficher dans la customView principale.

    Je suis étonné que les bindings, action, iboutlet fonctionnent dans ma customView, malgré mon code bizarre  :-\\

    En fait j'ai utilisé la CustomView à  la place du contentView

  • regattaregatta Membre
    20:40 modifié #5
    L'utilisation d'une customView est elle possible ou je dois changer de piste ?  ???


    Une autre question : le window.contentView retourne t'il le contenu de la fenêtre (une vue englobante implicite) ou la méthode de créer une view autour du contenu de la fenêtre (makeSubviewOf) est-elle nécessaire pour retourner le contenu d'une fenêtre dans une vue ?  :-\\
  • regattaregatta Membre
    20:40 modifié #6
    Pour expliquer ce que je souhaite pour mon code, voici mes besoins :
    • Avoir tout dans une seule fenêtre (gérée dans une Cocoa application)
    • Séparer la gestion des différents éléments de la base (code pas trop volumineux pour chaque classe)


    J'utilise donc une sous classe de NSDocument et de NSWindowController ainsi qu'un fichier nib pour chaque type de données à  gérer.

    Voici les interfaces dans les 2 cas (fichiers joints).



    [Fichier joint supprimé par l'administrateur]
  • 20:40 modifié #7
    Utiliser des NSDocument vaut le coup si tu comptes faire un fichier par fiche. Or là  ça m'a plus l'air d'être une base de données relationnelles, donc je vois pas ce que ça vient faire là  dedans.
  • regattaregatta Membre
    août 2006 modifié #8
    dans 1156622691:

    Utiliser des NSDocument vaut le coup si tu comptes faire un fichier par fiche. Or là  ça m'a plus l'air d'être une base de données relationnelles, donc je vois pas ce que ça vient faire là  dedans.


    En fait j'ai des fichiers :
    • un fichier par fiche de minéraux (rtf) que je garde à  jour,
    • un fichier au format xml des points GPS du site que je lis de la sauvegarde du gps ou que je j'exporte pour le gps.

    De plus, je gère mes menus pour chaque NSDocument.

    Mais effectivement l'utilisation de NSDocument n'est pas forcement utile  :(
    mais il me semble que l'on parle de MVC même dans le cas d'une base de données !

    Pour respecter le MVC, en séparant les types de données de la base et en affichant tout dans une seule fenêtre, voilà  la solution miracle que je recherche dans cocoa.
    Simple non  ;)
  • 20:40 modifié #9
    Bien sûr qu'on parle de MVC même dans le cas d'une base de données. Simplement, si le modèle est 'tordu', il est difficile d'avoir de bonnes bases pour faire le C et le V.

    Pourquoi stocker par exemple les fiches de minéraux dans des fichiers séparés alors que tu peux facilement transformer le RTF en données de type binaire (avec les bindings c'est même automatique) et stocker le tout dans une base, avec une "fiche" par minéral.

    De même pour les données GPS. C'est nettement mieux que tu fasses une classe pour les imports et une autre pour les exports, mais que ton soft ne sache traiter que les données stockées dans la base.

    De cette manière tu auras une manière homogène de traiter les données de différents type, et ça ira tout seul par la suite: tu fais un contrôleur central qui n'a pour seule fonction de recevoir des contrôleurs secondaires. Une fois qu'on lui a fournit un contrôleur secondaire, crée un nouveau tabitem avec la vue que le contrôleur secondaire lui propose (éventuellement une entrée dans une table si tu ne veux pas du système habituel pour les tabs), et puis il fournit au contrôleur secondaire une référence vers la base de données.
  • regattaregatta Membre
    20:40 modifié #10
    dans 1156671765:

    Bien sûr qu'on parle de MVC même dans le cas d'une base de données. Simplement, si le modèle est 'tordu', il est difficile d'avoir de bonnes bases pour faire le C et le V.


    Mon modèle est peut-être tordu, mais c'est un autre sujet  ;)

    dans 1156671765:

    Pourquoi stocker par exemple les fiches de minéraux dans des fichiers séparés alors que tu peux facilement transformer le RTF en données de type binaire (avec les bindings c'est même automatique) et stocker le tout dans une base, avec une "fiche" par minéral.

    De même pour les données GPS. C'est nettement mieux que tu fasses une classe pour les imports et une autre pour les exports, mais que ton soft ne sache traiter que les données stockées dans la base.


    Pour les fiches, j'utilise les bindings effectivement mais aussi une sauvegarde sur fichier. C'est un peu ceinture et bretelles (2,5 Mo de données que je modifie au cours de mes tests et que je ne veux pas perdre ! , mais ce n'est que provisoire)
    Pour les données XML, j'ai effectivement une classe d'import et une autre d'export.

    dans 1156671765:
    De cette manière tu auras une manière homogène de traiter les données de différents type, et ça ira tout seul par la suite: tu fais un contrôleur central qui n'a pour seule fonction de recevoir des contrôleurs secondaires. Une fois qu'on lui a fournit un contrôleur secondaire, crée un nouveau tabitem avec la vue que le contrôleur secondaire lui propose (éventuellement une entrée dans une table si tu ne veux pas du système habituel pour les tabs), et puis il fournit au contrôleur secondaire une référence vers la base de données.


    Là , je décroche pour le contrôleur central et les secondaires par rapport aux classes cocoa :(
  • 20:40 modifié #11
    Mais pourquoi faudrait-il qu'une solution toute faite existe dans Cocoa? Pour avoir un tel mécanisme, il suffit foncièrement de faire 2 classes et il doit y avoir moins de 20 lignes de code (sans les .h) pour y arriver. J'ai mis un projet en exemple.

    [Fichier joint supprimé par l'administrateur]
  • regattaregatta Membre
    20:40 modifié #12
    Un petit bout de code est plus clair qu'un grand discourt 

    Je n'avais pas vu qu'un NSTabView pouvait ne pas avoir d'onglet visible !

    Merci et A+
Connectez-vous ou Inscrivez-vous pour répondre.