›

Structure d'une application pour les nuls

BornToBeCocoaBornToBeCocoa Membre
19:00 modifié dans API AppKit #1
Hello,

En tant que débutant, il y a quelquechose que je ne comprends pas sur la manière dont une application Cocoa doit être structurée. Je m'explique :

1. Je crée une application "normale", pas Document Based.
2. J'ai une ressource qui s'appelle MainMenu.nib qui ne contient que la barre de menu. Je lui associe un AppController.h et un AppController.m pour contrôler la barre de menu.
3. Je crée une ressource qui s'appelle MainScreen.nib à  laquelle j'associe MainScreen.h et MainScreen.m pour gérer l'interface principale, par exemple une liste d'employées. Pas de problème pour sauvegarder la liste (Save), la charger (Load), la trier dans tous les sens, etc...
4. Je crée une ressource qui s'appelle EditForm.nib à  laquelle j'associe EditForm.h et EditForm.m pour gérer la saisie des employés : en fait c'est un formulaire de saisie.
5. L'interface principale (créée en 3) contient un boutton Créer un nouvel employé. Quand on clique dessus, le formulaire de saisie apparaà®t.
6. Lorsque la saisie est terminée et qu'on clique sur le boutton créer l'employé, ben là  je sais plus quoi faire pour renvoyer le résultat de la saisie dans le tableau qui gère la liste en 3.
J'ai bien essayé d'appliquer l'exemple SimpleMultiWindow fourni par Apple mais pour y arriver il faudrait que MainScreen soit delegate de l'application : NSApp delegate] methodeDansMainScreen:[resultatDeLaSaisieDansEditForm;
Or MainScreen ne peut pas être delegate de l'application puisque c'est AppController (créé en 2) qui l'est.

:'( Au secours, je suis paumé. La seule solution que je vois ce serait de sauvegarder la saisie dans EditForm, d'envoyer une notification à  MainScreen et de recharger le fichier sauvegardé à  partir de MainScreen. Mais c'est tellement tordu qu'il y a forcement mieux à  faire, notamment renvoyer simplement le résultat de la saise dans le tableau qui permet de gérer la liste.

Je cherche des exemples de programmes un peu partout mais à  chaque fois que j'en trouve un du style carnet d'adresses, finances personnelles, l'exemple RaiseMan dans Cocoa par la pratique... tout est géré dans une seule ressource .nib et ça, je sais faire. Mais dans ce cas il n'y a pas le problème d'ouvrir une nouvelle ressource pour la saisie et de renvoyer le résultat de la saisie.

:adios!: Kekun peut-il m'aider ?

Réponses

  • deftones_chrixdeftones_chrix Membre
    19:00 modifié #2
    Il est tard et je suis sans doute fatigué, mais j'ai l'impression que tu n'utilises pas le File's owner des fichiers nib.

    Si c'est bien le cas, n'oublie pas que tu peux le "customiser" avec une classe (dans le panneau information de IB, la section "custom class")  ce qui te permet d'avoir accés aux outlets et autres actions de cette classe.
    En espérant que cela te sois utile  :D
  • odjauodjau Membre
    19:00 modifié #3
    dans 1098742728:

    Il est tard et je suis sans doute fatigué, mais j'ai l'impression que tu n'utilises pas le File's owner des fichiers nib.


    Débutant de longue date je n'ai pas encore bien saisi l'intérêt et l'utilité (je ne doute pas qu'il y en ai :P) de File's owner. Quelqu'un peut il éclaire ma pauvre lanterne  :'(

    Merci d'avance  o:)
  • muqaddarmuqaddar Administrateur
    19:00 modifié #4
    Tien, j'ouvre un thread sur le File's owner dans le glossaire.
  • mpergandmpergand Membre
    19:00 modifié #5
    Ce problème a déjà  été évoqué ICI

    Mais dans ton cas, je crois que tu te compliques la vie pour rien. Les fichiers nibs permettent de regrouper des ressources et des classes, qui forment un module autonome et indépendant du reste de l'appli (NSDocument en est le parfait exemple)

    Dans ton exemple, tu as séparé des éléments qui visiblement sont trés liés ( MainScreen et EditForm) c'est certainement inutile et source de complication...

    Bien sûr on peut le faire à  ta façon, mais il faut recoller les morceaux( fichiers nibs) et pour cela il te faut une classe externe à  ces nibs: le fameux file's owner.

    Une fois un fichier nib chargé, les références aux différents éléments contenus dans ce fichier sont perdus (fenêtre, controler ...) c'est donc grâce au file's owner, dans lequel on définit des outlets sur ces éléments, que l'on va récupérer leurs références (initialisés au chargement du nib) Ensuite tu communiqueras ces références aux classes qui en ont besoin, pour EditForm la fenêtre MainScreen dans ton cas.

    Mais c'est bien compliqué cette histoire, si tu regroupes tout ça dans le même nib, tu peux faire ces liaisons directement dans ce nib.

    Le cas ou une séparation serait justifiée, serait celui où tu aurais plusieurs fenêtre de données avec leur fenêtre de saisie associée, dans ce cas effectivement tu créerais une instance de la fenetre de saisie pour chaque fenêtre de données (est-ce ton cas ?). [ bof, c'est même pas un bon exemple, finalement ;D]

    Voilà , j'espère n'avoir pas été trop confus :D
  • odjauodjau Membre
    19:00 modifié #6
    dans 1098774956:

    Tien, j'ouvre un thread sur le File's owner dans le glossaire.


    Merci  o:)
  • BornToBeCocoaBornToBeCocoa Membre
    novembre 2004 modifié #7
    :crackboom:-
    Hello,

    Après une bonne semaine de réflexion et plusieurs essais, je viens de comprendre ce qui n'allait pas.

    En fait je n'utilisai pas correctement le concept Model View Controller (j'avais pô complris komin k ça mâlrche). La classe EditForm contenait la gestion de l'interface et de l'employé. Bouh, pas bon  :-\

    Maintenant j'ai créé une classe Employe (le modèle). Ainsi il est très facile d'envoyer des message au modèle pour modifier ses variables via n'importe quelle interface ou appeler le modèle pour lire la valeur de ses variables et les afficher dans n'importe quelle interface. Du coup des tas de problèmes se sont débloqués.

    J'ai l'impression d'avoir fait un grand pas. Ca fait tout drôle...  :spot:

    En tout cas, merci à  tous pour votre aide.
Connectez-vous ou Inscrivez-vous pour répondre.