Les bindings
iShadow
Membre
Bonjour à tous !
Je ne suis qu'un jeune programmeur débutant (très débutant) et je voudrais vous poser une questionqui fera sans doute rire tous les boss de la prog Cocoa : que sont les bindings ?
J'ai lu le tutorial concernant ceux-ci sur ce site, j'ai d'ailleurs été très impressionné par leur effets, mais ce tuto n'explique pas trop que sont les bindings et cela serait super si on pouvait me l'expliquer en termes simples (sachant que je ne comprendrai rien si je lisait leur définition brute
)
En tout cas ce site est vraiment super et l'ambiance qui règne sur ce forum est vraiment très bonne. Continuez comme ca ! :adios!:
P.S. : je suis actuellement en train de créer une toute petite appli qui, je pense, peut (un peu) servir (perso je l'utilise pour m'endormir en musique...). Elle est loin d'être aboutie et de nombreuses fonctions ne sont pas présentes, mais en tout cas la base marche... Vous pouvez la télécharger ici : http://macxshadow.free.fr/Pages/application.php?titre=TimeMaster
Je ne suis qu'un jeune programmeur débutant (très débutant) et je voudrais vous poser une questionqui fera sans doute rire tous les boss de la prog Cocoa : que sont les bindings ?
J'ai lu le tutorial concernant ceux-ci sur ce site, j'ai d'ailleurs été très impressionné par leur effets, mais ce tuto n'explique pas trop que sont les bindings et cela serait super si on pouvait me l'expliquer en termes simples (sachant que je ne comprendrai rien si je lisait leur définition brute
)En tout cas ce site est vraiment super et l'ambiance qui règne sur ce forum est vraiment très bonne. Continuez comme ca ! :adios!:
P.S. : je suis actuellement en train de créer une toute petite appli qui, je pense, peut (un peu) servir (perso je l'utilise pour m'endormir en musique...). Elle est loin d'être aboutie et de nombreuses fonctions ne sont pas présentes, mais en tout cas la base marche... Vous pouvez la télécharger ici : http://macxshadow.free.fr/Pages/application.php?titre=TimeMaster
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Hum, t'es sur
Je pense qu'il faut que tu t'address à ClicCool, le bindingologue. Mais je pense le griller un peu.
Les bindings sont basés sur le principe modele-vue-controller. CaD que ton code ne doit se composé de trois parties : un modéle qui est un objet qui n'a absolument aucun lien avec l'UI (pas d'outlet, ni d'action) ; une vue qui gére l'affichage et qui recoit certaines actions ; et le controleur qui tient un peu le role de tampon ( il contient des objets de type "modele" et demande à la vue de les afficher).
Ce principe permet de limiter grandement la quantité de ligne de code.
Ainsi, tu peut "binder" une tableView, une textView, beaucoup de chose en fait. Pour l'utilisation des bindings, je te recommande les articles de ClicCool :
http://www.objective-cocoa.org/index.php?p=article&visite=&id=6
http://www.objective-cocoa.org/index.php?p=article&visite=&id=4
http://www.objective-cocoa.org/index.php?p=article&visite=&id=5
A toi ClicCool
C'est puissant les bindings...
Mais one more thing : comment les bindings marchent ? Ils creent un .plist dans le dossier préférences, ils stockent les infos dans le code de l'appli, ... ?
@+
P.S. : tu va jamais sur iChat toi ? :P
Je sais pas trop, mais je pense que c'est rangé qq part dans tes nibs, et oui, les bindings, c'est puissant
He he >:D, non, jamais. Mes copains me tannent d'ailleur avec ca
Lol, c'est dommage... Tu devrais tu sais, l'échange d'infos c'est vraiment top :fouf):
Sinon pour revenir au sujet,
les bindings remplace le fait de créer des .plist c'est cela non ?
@++ (peut être sur iChat)
Donc les prefs sont stockées dans un fichier .plis appelé par défaut : com.apple.nomdelapp.plist
Enfin je pense ???
Moi j'utilise le NSUserDefaults mais sans passer par les bindings..
je pense que les bindings simplifient juste les choses au développeur :-\\
Insûreté totale
Pas du tout ;-) ... tu mélanges quelques concepts..le binding s'appuie les mecanismes de key-value coding (codage par clé-valeur) et key-value observing (observation clé-valeur).
Pour comprendre mieux comment fonction le Key-Value Binding (KVC + KVO = KVB) je te conseille la lecture de ce document :
http://www.projectomega.org/article.php?lg=fr&php=oreilly_cocoa37&p=1
En un (ou presque) mot:
Les bindings ne tiennent pas à jour la moindre trace des model-objets contrôllés, pas de plist ni autre...
Ils sont basés sur l'observation des changements qui passent par un setter KVO et 'lisent' les valeurs par le getter KVO. Si un changement schunt l'accesseurs ils sont 'bluffés' et ne voient rien.
Les contrôlleurs sont parfois élaborés comme les arrays contrôllers qui sont capables de stocker l'état des tris et sélections faits sur l'array modèle.
Pour l'instant les bindings paraissent puissants mais ils ne sont pourtant que les bases d'un projet nettement plus ambitieux (cf Tiger) capables de lier directement la représentation graphique ( ainsi que les tris mais aussi les inter-relations etc...) avec les fichiers stockant les modèles.
Un peu comme les NSUserDefaultsController. Saufs que ceux-ci sont encore très limités: format plist des prefs (avec tiger SQLlite sera directement 'bindable') et surtout ils ne savent pas gérer les modifs sur une collection (ils transmettent un array issu des prefs sous forme immutable uniquement).
C'est sur! Eaglelouk
Et au passage, bienvenu sur O.C. !
Bien sûr, j'ai compris quelque chose, mais j'avoue mon incompétence totale concernant les termes "model-objets", "schunt" et "key-value" ???
Désolé d'être si nul !!!
Mais je pense que tous s'éclaicira si je pouvais comprendre la notion d'observer. En effet, je possède le livre "Cocoa par la pratique", mais celui-ci s'adresse visiblement à des personnes sachant dejà bien programmer. Et les notions telles que observer ou coder, ben je les pige vraiment pas...
Si l'on pouvais éclairer ma lanterne... :why?:
En tout cas, merci pour tout, c'est vraiment génial ce que vous faites.
@+
Nos appli manipule ces données, les représente souvent dans l'interface utilisateur etc... Mais les données elles-même doivent rester indépendantes de ces manipulations. Tout cela est assez bien shématisé par le fameux Model-View-Controller design pattern (A lire absolument)
Schunt n'est pas vraiment un terme de codeur, ça veut simplement dire accéder directement en contournant le chemin attendu (ici en contournant les accesseurs)
Le Key-Value-Coding est une norme d'écriture et d'appellation des accesseurs aux variables qui, lorsque leurs accesseurs obéissent à la syntaxe KVO deviennent alors des propriété (variable) KVC Compliantes et permettent alors aux bindings de les "observer" (KVO) c'est à dire en gros de recevoir une notification les prévenant chaque fois qu'une méthode KVC est appelée.
En gros un observer est un objet qui s'est déclaré auprès un centre de notification pour être notifié à chaque fois qu'un (des) évènement survient sur un (des) objet.
J'espère avoir été un peu plus clair ?
@+ iShadow
Tout à fait, le shuntage est a l'origine utilisé dans des circuits électriques pour contourner un matériel, et le parallèle avec la programmation est vite fait...:)
euh hem !
pour moi, un shunt c'est surtout un pont (naturel mais pathologique ou artificiel mais thérapeutique ...) courtcircuitant le parcours naturel du sang dans la circulation sanguine ... ::)
Le terme peut même être utilisé au figuré lorsqu'un salarié shunt son supérieur direct pour s'adresser au "chef-du-chef" (c'est mal vécu en général
Au monopoly mieux vaut ne pas shunter la case départ en tout cas :)beta:
Mais t'as raison Eddy le mot court-circuit est celui qui se raproche sans doute le mieux de la notion de shunt.
Oui docteur. ;D
Rigoles !
en attendant regardes: définitions de Shunt
T'as 1 référence à l'électicité pour 10 à la médecine ! ;D
Allez c'est pas tout ça, qu'est-ce que je te sert ?
http://www.websters-online-dictionary.org/definition/english/Sh/Shunt.html#Definitions
En tout cas ClicCool, je perds pas mes habitudes (mais est-ce raisonnable a cette heure-ci ? :P), et je prendrais un jaune bien frais avec un bon gros glaçon.(j'ai pas dis une soupe hein
Je me penche actuellement sur la notion de bindings depuis que je me suis rendu compte que je n'avais pas compris ce que c'était ^^
Et donc il y a une question qui me taraude. Je lis un peu partout que KVC/KVO, le coeur des bindings permet l'accéder aux variables d'instances via leur "nom" le K de KVC/KVO. Bien bien, mais...à quoi ça sert? On me dit ici que c'est très puissant, (cf shuntage thérapeutique plus haut ^^) mais on peut déjà accéder à tous ça via les... get/set, qu'est ce que les bindings apportent de plus?
Perso j'ai pas du tout accroché aux bindings et j'ai opté pour du codage pur et dur
L'intérêt du KVO me semble évident : observer une variable, et en être informé quand elle change (puisque c'est le principe du Key-Value-Observing), cela peut avoir plein d'applications, comme mettre à jour l'interface dans le cas où une variable de ton modèle change, pour afficher ce changement, etc.
Le KVC, pour te donner un exemple, je m'en sers pour gérer dans mon appli toute une structure de données que j'ai à modifier. J'ai des formulaires divers et variés dans mon appli, et à chaque champ de mon "formulaire" j'associe un keyPath, qui n'est donc rien d'autre qu'une NSString* formattée sous forme "machin.truc.bidule", et qui me dit ce que je vais modifier dans ma structure de données. Comme ça quand je suis informé que l'utilisateur a changé le contenu de mon champ, je demande un simple [tt][mesDonnees setValue:contenuDuChamp forKeyPath:leKeyPathAssocié][/tt].
L'intérêt c'est que mes champs de formulaire sont génériques, je mets dans une chaà®ne de caractères l'identifiant (keypath) indiquant à quelle partie de "mesDonnees" je veux que mon champ soit lié, et ce pour chaque champ... et ensuite je fais autant de champs que je veux, liés aux bonnes données (donc avec le keyPath adéquat) et tout se fait tout seul.
Sinon j'aurais eu à faire du cas par cas, regarder si c'était mon champ numéro 1, et dans ce cas appeler [mesDonnees setToto:v] parce que mon champ 1 est lié à la donnée toto, ou [mesDonnees setTata:v] s'il s'agissait du champ 2 que je veux relier à la donnée tata... là je fais juste [mesDonnees setValue:v forKeyPath:kp] avec kp qui est une NSString valant "toto" pour mon premier champ et "tata" pour mon 2e, et il appelle les bons accesseurs tout seul, c'est magique.
Les bindings c'est génial
Les bindings me permettent de lier directement un TextField avec une propriété d'une ABPerson du carnet d'adresse sans écrire de code entre les deux ou presque ! Cerise sur le gateau les modifications sont sauvegardés avec une ligne de code : [book save]; !
Le secret qui n'en est pas c'est le '.' qui permet de lier laPersonne.name ou la personne.birthday ou n'importe quelle autre propriété déjà définie dans le carnet d'adresse. Suffit à chaque fois qu'on change d'enregistrement de faire self.laPersonne = cetteAutrePersonne pour que ça se répercute sur les champs..
Quand ça marche ça a un côté "magique"
PS: c'est mon premier post sur ce site. A 50 ans je développe pour mon plaisir, ça me plait plus que regarder la télé et Xcode est gratuit..
J'avoues que les bindings je nage encore beaucoup pour cause de pas assez de mise en pratique à mon avis. Mais je veux m'en servir dans les cas où c'est utile.
1) Les bindings, on peut se débrouiller sans.
2) Les bindings, on peut se débrouiller avec pour des situations simples, et c'est effectivement léger d'utilisation.
3) Les bindings, je les déconseille aux débutants/débutants++ quand cela devient un peu tordu, car les mécanismes sont masqués, et on perd beaucoup de temps à les démonter (quand on y arrive) .
Bienvenu dans le forum !
Probablement car on ne cherche pas beaucoup à savoir ce qui se cache dessous et on doit faire confiance à Apple.
Par contre ça permet de construire sans beaucoup de code une interface utilisateur liée à une classe modèle. Et, avec moi, moins il y a de code moins il y de mal ou plus il y a de mieux c'est comme on veut
Comme les propriétés, qui vont avec, moins de code, moins d'erreurs...
Une bonne analogie me semble les automobiles: ceux qui ne connaissent pas ne jurent que par les boà®tes manuelles alors que ceux qui ont maà®trisé les boà®tes automatiques ne regrettent que la consommation ajoutée :-) Et je dois reconnaà®tre que j'aime bien les boà®tes automatiques: on ne fait jamais de sur-régime, c'est presqu' aussi rapide (si pas plus) et, à l'usage, c''est moins fatiguant ... Bien sûr ça fait moins macho et on a moins le sentiment de prise directe sur la machine :-)
C'est dingue le nombre d'analogie que l'ont peu faire avec les vroumvroum
Sinon on peu demander à Apple de passer tous ça en open source et puis comme ça on saura ce qu'il y a sous le capot
Oui mais un vrai projet c'est pas toujours un gros joufflu
Il peut y en avoir des petits perso, chacun voit midi à sa porte ..
Et puis je suis en phase d'apprentissage, d'apprivoisement des objets Cocoa. Avec les bindings j'ai l'impression de les tenir en laisse (quand j'arrive à passer la laisse).
Bien sûr si je devais avoir beaucoup de laisses je préférerais probablement avoir domestiqué tous mes objets. Mais pour l'instant j'en ai peu à gérer et ça me plaà®t bien comme ça. De toutes façons l'un n'empêche pas l'autre donc l'avenir ne m'angoisse pas non plus