NSObjectController et les bindings
muqaddar
Administrateur
Philippe49 a "pondu" un article très simple sur l'utilisation des Bindings avec NSObjectController.
Il le met à disposition dans cet article (à télécharger au format PDF).
[Fichier joint supprimé par l'administrateur]
Il le met à disposition dans cet article (à télécharger au format PDF).
[Fichier joint supprimé par l'administrateur]
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Que demander de mieux.
Plutôt NSObjectController et bindings, le tuto de clic-cool étant déjà tout à fait satisfaisant sur le sujet des NSArrayController
J'ai fait une mise à jour du Reader, le problème persiste!
Quelqu'un a une idée?
Suivre
consulter les articles
puis fichiers
Super tutoriel !
Dommage qu'il n'y en a pas plus de ce genre, pratique pour apprendre ...
Par contre je sèche à un endroit ... Page 8, page 9.
Je vous remet ces 2 pages en fichier joint et, j'ai donc crée cette nouvelle classe que l'on nomme CelsiusToFarenheitTransformer, mais après je ne comprend plus:
- Comment en faire une sous classe de NSValueTransformer? avec ?
- Mais ou dois je coder le contenu de la page 9? dans quelle classe?
Merci.
Salut bodysoulspirit,
Pour créer une sous classe il faut créer
- un descriptif de celle-ci (avec le NOM des classe parente, variables d'instances, méthodes de classes et méthodes d'instances) que l'on met classiquement dans en fichier d'interface type header en .h
- Le code correspondant qe l'on mets classiquement dans un fichier d'implémentation en .m
Par chance xCode facilite un peu le travail.
Dans xCode, choisi menu File -> new File ...
La fenêtre Assistant apparaà®t alors
Choisi ici Cocoa -> Objective C Class
Donne lui le nom de ton transformer (ici ce serait CelsiusToFarenheitTransformer) et valide
2 fichiers sont ajoutés à ton projet.
Ouvres le Header en .H ( ici CelsiusToFarenheitTransformer.h) Remplace juste NSObject par NSTransformer
Ton transformer hérite de NSTransformer et c'est du reste la seule chose que dise ton fichier d'implémentation car
- Pas de variables d'instances à déclarer
- Pas de méthodes nouvelles propre à ta nouvelle classe à déclarer (les descriptions des Méthodes déclarées par NSTranformer dans NSTranformer.h seront héritées et suffisent ici)
Ouvres maintenant le fichier d'implémentation ( ici CelsiusToFarenheitTransformer.m) pour y taper le code propre à l'implémentation de ta nouvelle classe (le code que l'on a sur la page 9)
Il y a là le code d'implémentation de ta classe pour les méthodes déclarées dans sa superclasse.
Précisément Deux méthode de classe ( avec un + devant) et Deux méthodes d'instances (avec un - devant)
Et voilà ! tu viens de créer ta première sous-classe perso
@+
Mmm, merci.
Mais bon, je t'avoue que, après 3 jours de documentation cocoa sur le ADC apple + 2 jours a faire des tutoriels, je t'avoue que j'ai encore du mal à bien comprendre ce qu'est une la grande différence entre une classe, une méthode, un contrôleur, le fichier .h, le .m ...
P*****, le jour où je comprend tout ca je me lance dans un tutoriel hyper simple ...
Ou alors c'est moi qui suis con tiens, ça j'y avait jamais pensé ... Ou alors parce que je suis belge ... ou les deux ... :(renaud):
+
Il faut dire que cela est très riche ...
Tu as lu un bouquin comme celui d'Aaaron Hillegass ? Il date un peu, et depuis son édition il y a eu des évolutions, mais il est vraiment très bien fait à mon avis, fixant un certain nombre de bases qui restent toujours d'actualité.
- Méthode : c'est une fonction associée à une classe, et qui est disponible alors pour cette classe (ou plus précisément les objets qui sont des instances de cette classe) et ses sous-classes éventuelles.
- Classe : sorte de "modèle" servant à créer des objets. On dit qu'on instancie une classe C, ou que l'on crée une instance O de la classe C, lorsque l'on crée un objet O en se basant sur le "modèle" défini dans la classe C.
- Variable d'instance : c'est une variable associée à une classe. Chaque instance de la classe possède alors les variables définies dans la classe. Chaque instance différente peut posséder des valeurs distinctes dans ces variables.
Exemple : on peut avoir une classe "Voiture" qui contient 3 méthodes "démarrer", "arreter" et "klaxonner", et 3 variables d'instance "marque", "couleur" et "immatriculation".
--> On peut alors créer 3 voitures distinctes (on a expliqué plus haut à notre programme, grace à la classe "Voiture" justement, ce que l'on appelais de manière générale une "voiture", de quoi elle était composée (variables d'instance) et ce qu'elle savait faire (ses méthodes). Chacune des 3 voitures, donc des trois objets qui seront des instances de la classe "Voiture", auront chacune une couleur, une plaque d'immatriculation et une marque (qui pourront être différentes pour les 3, genre une Renault rouge, une Seat verte et une Peugeot bleue). Et chaque voiture saura comment démarrer, s'arrêter et klaxonner.
- Contrôlleur : sorte particulière de classe (ou d'objet, selon le contexte, on parle "du/des contrôlleur(s)" (objet(s)) ou de la classe contrôlleur) qui est dédiée à faire communiquer l'interface (ton IHM créée avec InterfaceBuilder) et ton modèle (représentation interne de tes données).
- Fichier ".h" et ".m" : pour définir une classe, cela se fait en 2 parties. D'abord on la décrit, on dit qu'on fait sa déclaration, donc on ne fait que lister ses méthodes et ses variables d'instance, ce qui se fait dans un fichier à l'extension ".h". Ensuite on la définit, c'est à dire que pour chaque méthode de la classe, on détaille son code. Ceci se fait dans le ".m".
--> Donc dans "Voiture.h" on va juste dire qu'une voiture a une marque, une couleur, une immatriculation, et 3 méthodes (et donner leur signature respective, c'est à dire leur nom, le type de leurs paramètres et le type de donnée qu'elle retourne). Et dans "Voiture.m" on va écrire le code de chacune des méthodes "démarrer", "arrêter" et "klaxonner".
Le ".h", donc "l'interface", permet de dire à celui qui le lit "je t'informe de ce que sait faire une voiture. T'as pas besoin de savoir comment elle se démerde pour démarrer ou s'arrêter ou klaxonner, je te dis juste qu'elle sait le faire". Le ".m" est là pour coder, mais celui qui ne fait qu'utiliser la classe "Voiture" une fois qu'elle sera au point n'a pas besoin d'aller lire le ".m".
Ainsi tous les "trucs tout faits" (librairies et frameworks, en gros un ensemble de classes toutes prêtes à l'emploi) ne fournissent que les ".h" pour l'utilisateur final, qui ne voit pas le code du ".m" (déjà compilé dans la librairie). Tu peux lire les fichiers "NSNumber.h" pour savoir ce que sait faire un NSNumber, mais t'as pas à savoir comment à l'intérieur Apple s'est démerdé pour coder ça, du moment que tu sais les méthodes disponibles et ce qu'elles sont sensé faire.
J'ai hâtivement décrit dans "méthodes" uniquement les méthodes d'instance sans décrire les méthodes de classe.
- Une méthode d'instance est une méthode disponible pour chaque instance de la classe. Elle dépend potentiellement de l'objet (l'instance) sur laquelle elle s'applique, et on l'appelle "sur l'objet", en demandant à une instance O de notre classe de répondre à cette méthode. Par exemple une méthode "afficheCouleur" de ma classe "Voiture" doit être une méthode d'instance, car ça n'affichera pas la même chose selon la voiture, chaque voiture pouvant avoir une couleur différente (c'est pour ça qu'on précise à quelle voiture on envoie le message, ie. sur quelle voiture on appelle la méthode).
- Une méthode de classe est une méthode que l'on appelle sur la classe elle-même. Elle ne peut alors pas dépendre des variables d'instances (non "static") dont les valeurs sont potentiellement différentes entre deux instances de la même classe. C'est pour ça que la méthode "afficheCouleur" ne peut pas être une méthode de classe, il faut savoir de quelle voiture précisément on veut la couleur. Par contre on peut demander le nombre de roues, qui ne dépend pas de l'objet sur lequel on appelle la méthode. En gros ça revient à poser la question "tiens, combien une voiture, quelle qu'elle soit, possède-t-elle de roues ?".... et on a même pas besoin d'avoir créé une voiture (donc d'avoir une instance de la classe Voiture) pour avoir la réponse, on pose la question à la classe pas à une instance !
Voilà voilà .
PS/PJ : ClicCool, n'oublie pas la lumière des chiottes. :brule:
Ne t'inquiète pas, ça se soigne.
Il a commencé sa thérapie...
Quoiqu'il n'a pas choisi le meilleur lieu : d'après son profil, il est en Alsace, la pire région de France (après le Nord, bien sûr) !
.
Eh ben Aligator, ça c'est sympa, une petite explication pas anglophone ! Merci.
Merde alors, je me suis encore fait avoir...
Non, la France est vraiment le plus beau pays, heureusement que Dieu a crée les français pour équilibrer un peu avec les autres pays
Quelqu'un me cherche là ?
Fait Gaffes à l'expulsion !
C'est dans la charte du forum (ou si ça y est pas c'est qu'elle est mal faite): on touche pas à Marseille SVP
Il est sympa ce gars là
Ceci dit, pas pour dire, contradiction interdite, >:D rien ne vaut l'Anjou et le coteau du Layon
Je connaissait pas le le coteau de Layon ...
Tu perds rien, beaucoup trop sucré à mon goût >:D
Et ça vaut pas une bonne soupe 15 de Marseille :fouf):
http://www.layon.org/
ClicCool, tu sais comment on reconnaà®t une vielle Lada ?
rép: Il y a un autocollant "Marseille champion" collé à l'arrière...
du layon
C'est une sorte de vin blanc comme le Jurançon, le Sauternes, ... idéal avec foie gras, en apéritif, au dessert ... Il y a une version encore plus subtile mais très locale, le Coteau de l'Aubance, avec des arômes de fruits secs.
Bon mais là -bas en Alsace, il y a de quoi faire aussi non ? on y a tous de beaux souvenirs ...
Meuh non, il faut le prendre de qualité, et le servir à bonne température, i.e quasi frappé.
C'est comme les vins d'Alsace, il faut bien les choisir ...
Ah oui évidemment, je m'incline
Euh là , il va faire mauvais temps ...
attendons la réponse de Clic Cool
Oui, c'est clair qu'il la pas encore vu ...
Je profite de mes derniers instants sur ce forum ... Je profite ...
Bien sur on en retrouve aussi dans les fouilles archéologiques des "Marseille Champion"
ça fait tellement longtemps qu'on est champions.
C'est pas comme ça qu'il fallait te lire ?
Ici on raconte la même avec le PSG
Mais je me permettrais pas, les supporter du PSG ont forcément un grand coeur pour soutenir par pitié une telle équipe :P
Pour l'instant tu profittes encore un peu de l'immunité des nouveaux à qui on excuse les erreurs de jeunesse.
Mais attention, on excuse mais on n'oublie pas ! >:D
Ah ben tu vois, ça c'est sympa ! Ma mère m'a toujours dit, depuis tout petit, "si tu te fait virer d'objective cocoa, tu ira garder les chèvres dans le Pyrénées et ramasser les crottes de chat"
et de toi à moi, j'ai vraiment pas envie d'aller garder les chèvres.
Ta maman est d'une grande sagesse.
Eh ben, un marseillais qui dit d'une mère belge qu'elle est la sagesse ... Eh ben ! Ca s'est pas rien !
Ben tu sais, j'ai la chance, que dis-je ? le privilège !, d'en connaitre une de maman Belge.
ET je t'assures qu'elle gagne à être connue.
C'est vrai que c'est peut être pas "la sagesse même" qui me vient forcément en premier à l'esprit à son sujet mais pas mal d'autres pensées affectueuses vont à elle
.../...
En y réfléchissant c'est vrai, qu'à ce que je sais, elle est parfois, comment dire ?, dans les airs.
Mais tant que chaque décollage est suivi d'un attérissage sans bobos tout va pour le mieux
PS: T'as remarqué ? J'ai mis une Majuscule !
On pourra pas dire que vous êtes pas sympa sur ce forum !
On l'aime notre petit coin d'anjou :-D (Bon ok maintenant je suis en Bretagne et je crache pas sur les crèpes et le cidre non plus, mais bon)
Bon en même temps on a aussi la soupe angevine, de notre côté, hein :-D
(Mais bon c'est pas pour autant que je dénigre les spécialités marseillaises... y'a du bon à prendre partout ;D)