Explication de texte...

odjauodjau Membre
09:54 modifié dans API AppKit #1
Salut tout le monde,

je suis debutant, et en lisant les divers threads de ce forum je me rend compte que la chose qui me bloque le plus pour comprendre,c'est que j'ai du mal à bien saisir l'ensemble des concepts qui ce cache derière certains thermes.
ClicCool à parfaitement réussi à expliquer les bindings sur un autre forum† ;) (http://macfr.com/forums/index.php?s=1ea9bb011fb66d45ca08d6d3aca7563e&showtopic=12488) encore merci pour tout ce travail.

Serait-il possible d'expliquer le concept de "data source" qui revient souvent.

Si quelqu'un peut éclairer ma lanterne (et celle d'autre débutant ;)), je lui en serais fortement reconnaissant.
Merci d'avance
@+

Réponses

  • TiffTiff Membre
    09:54 modifié #2
    Certains objets simples de l'interface sont entièrement contrôlés par le Controller.
    Par exemple, si tu as un champ de texte monTexte, tu vas lire ou écrire par les messages :
    phrase = [monTexte stringValue] ou [monTexte setStringValue:@Salut !]

    Maintenant, il existe des objets plus complexes, en particulier les tableaux (NSTableView) qui peuvent contenir des dizaines de cases (cellules ?). Hors de question de toutes les contrôler manuellement !
    Ainsi, on demande au tableau de s'autogérer, mais, pour afficher les bonnes valeurs dans les bonnes cases, il a besoin d'aller chercher les données dans un objet particulier : le datasource. Généralement, le datasource est un Controller.

    En pratique, dans MonControleur.h, on déclare une liste NSMutableArray *maListe. C'est la liste des objets qu'on veut voir afficher dans le tableau.
    Dans MonControleur.m, on implémente les méthodes numberOfRows (qui va indiquer au tableau le nombre de lignes, en général c'est le nombre d'objets de la liste [maListe count]) et une autre méthode dont j'ai oublié le nom, mais qui indique colonne par colonne quelle valeur il faut afficher.

    Dans monControleur.m, on n'appelle jamais ces deux méthodes, c'est le tableau NSTableView qui les appelle (quand on lui demande de se mettre à jour) via l'outlet dataSource.

    On peut aussi imaginer une vue personnalisée (maVue, sous-classe de NSView) qui affiche une liste de dessins (des cercles, des triangles). Comme il n'est pas très logique que ce soit maVue qui déclare la liste des dessins, on se sert d'un contrôleur et on connecte maVue à monContrôleur par un outlet sourceDeDonnees ou n'importe quel autre nom. Le nom dataSource n'est pas obligatoire, mais est très explicite.

    J'ai tout bon ?
  • molgowmolgow Membre
    09:54 modifié #3
    J'aurais plutôt expliqué la notion de data source au regard du paradigme Model-View-Controler (MVC).

    Le but du MVC est de séparer ce qui concerne l'affichage (View) et les données (Model). Dans le cas d'un NSTableView, ce que contient la table n'est pas contenue dans la classe NSTableView elle-même. Mais cette classe (qui est une sorte de View-Controler) contient une référence sur un objet "data source" qui lui s'occupe uniquement de gérer les données que contient la table.

    L'avantage de cette séparation c'est que l'affichage des données et les données elles-mêmes sont complétement séparées. On pourrait par exemple imaginer que pour un programme, on ait besoin d'un NSTableView particulier (avec une interface graphique différente, par exemple à la iChat). Dans ce cas, le programmeur qui s'occuperait de l'interface graphique peut tranquillement faire un sous-classe de NSTableView et la modifier sans que cela affecte la gestion des données elles-mêmes.

    Voilà, j'espère que je raconte pas de bêtises... :)

  • odjauodjau Membre
    09:54 modifié #4
    Merci pour vos réponses.

    Pourquoi ne pas lancer un autre thread sur MVC ? Je crois que Nucleus dans un autre poste avait dit quelque chose comme


    Quelques phrases simples qui peuvent servir pour guider rapidement ta conception:
    La vue est liée aux yeux de l'utilisateur (représentation graphique)
    Le controlleur est lié aux mains de l'utilisateur (interraction avec souris, clavier..)
    Le modèle est lié à l'esprit de l'utilisateur (concepts abstraits indépendants de l'interface utilisateur)


    Avis aux spécialistes qui voudraient partager avec nous, les débutants, leurs connaissances sur les conceptes de base qui guide la POO et plus particuliairement Objective-C.
    Je peut donner quelques pistes ?† ::)
    MVC, framework?

    Je sais que le temps est une chose précieuse alors merci d'avance à ceux qui prendrons le temps de répondre.
    J'espère que je pourais bientôt faire parti de ceux qui répondent plutôt que de ceux qui posent des questions† :-\

    Au plaisir de vous lire
  • muqaddarmuqaddar Administrateur
    09:54 modifié #5
    T'inquiètes pas ptit bras, un jour on sera grand. Je fais pas mal de tutorials, même si je ne comprends pas toujours tout, et parfois, il faut même les faire 2 ou 3 fois ! Courage.

    Moi, on me l'a déjà expliqué mais j'ai encore du mal à comprendre les delegate...
  • 09:54 modifié #6
    Le delegate est un objet externe qui est informé sur les actions de l'utilisateurs et qui peut éventuellement renseigner l'objet qui l'a délégué.

    L'intérêt de faire ça sous la forme d'un objet à part est d'éviter d'avoir à sous classer, parce que dans bon nombre de cas ce sont les mêmes méthodes qui auraient à être écrasées, et d'autre part l'objet externe a accès a des variables d'instance qui peuvent être utiles.

    Pour te donner un exemple, dans les préférences de Word, tu as une table avec la liste des "panneaux de préférences", et à côté, tu as une tabview, mais où les tabs sont invisibles. Si le délégué est le controller, le fait qu'il soit renseigné d'un changement de la ligne sélectionnée permet de changer l'élément  visible dans la tabview.
    Le type d'information que peut donner un délégué est le plus souvent une autorisation. Par exemple, tu veux quitter une application. L'application informe son délégué que tu veux quitter, et lui demande s'il peux. Le délégué remarquera par exemple que tous les documents n'ont pas été sauvés, et informera l'application qu'elle ne peut pas quitter (après en avoir informé l'utilisateur).
    Un autre exemple d'information plus complexe est pour NSLayoutManager, qui permet de gérer l'affichage du texte sur plusieurs pages, dans un traitement de texte par exemple. Quand il a finit de mettre à jour l'affichage, il informe son délégué (un objet qui ajoute et supprime des pages) de la dernière zone utilisée, si elle existe (elle n'existe pas dans le cas où il n'y pas assez de pages). De cette façon, le délégué sait qu'il a à rajouter ou supprimer des pages.

    Voilà, j'espère que c'est plus clair pour toi.
  • muqaddarmuqaddar Administrateur
    09:54 modifié #7
    Merci Ardlon pour cette belle explication.
Connectez-vous ou Inscrivez-vous pour répondre.