Votre avis sur les bindings
Céroce
Membre, Modérateur
dans 1225664284:
Mon idée personnelle sur les bindings est de les réserver à des situations relativement simples. Si un programme doit prendre de l'ampleur, le bon vieux système du data source reste toujours plus facile à débugger et à faire évoluer. Mais il faut prendre cela comme un avis personnel.
J'ai la même idée personnelle. La première version de mon appli utilisait les bindings (et Core Data), et je dois dire que je me suis pris la tête avec eux. Autant le Key-Value Observing tient la route (je m'en sert extensivement dans la nouvelle version), autant les objets contrôleurs (NSObjectController, NSArrayController, NSTreeController) sont mal foutus et difficiles à modifier puisque la doc n'a pas prévu qu'on veuille le faire. En fait, tout ça, c'est bon pour faire joujou: ça marche tant qu'on utilise exclusivement les vues standard et des modèles simplistes. Le fait que NSArrayController ne soit pas fichue de remplir le dictionnaire changes dans la méthode - [observeValueForKeyPath:ofObject:change:context:] est un problème courant et qu'Apple ne considère pas régler un jour.
Le problème du débogage est réel: souvent, il nous est juste indiqué "la clef 'selection' n'existe pas", sur on ne sait trop quel objet. Trouver quel objet a essayé d'y accéder relève alors de la gageure.
Un autre soucis provient des Value Transformers. Passons sur le fait que -transformedValue et -reverseTransformedValue sont inversées de mon point de vue. Non, le souci, c'est qu'on passe son temps à en écrire. Par exemple, j'ai des transformateurs tout crétins, juste pour ajouter ou soustraire 1 à la valeur, parce que le premier n° de page est 1, mais que le premier indice du tableau est 0...
Un autre souci que j'ai eu: j'utilisais les bindings pour les vues de mon Inspecteur. Au début, ça marchait très bien: j'avais mes formes géométriques à l'écran: un rectangle, une ellipse, une étoile, et je pouvais changer l'épaisseur du trait et le remplissage.
J'ai voulu aller plus loin: permettre le réglage du nombre de branches de l'étoile. N'étant pas totalement idiot, je n'affiche pas le slider qui règle le nombre de branches quand la sélection ne contient pas que des étoiles. Pourtant, dès que je sélectionne un rectangle, ça plante: en fait, le slider est bindé avec la propriété "nombreDeBranches" dès que le .nib est ouvert; peut importe que le slider soit affiché ou non. Apple n'a pas prévu qu'on veuille désactiver momentanément les bindings. Il n'est pas non plus possible de récupérer le keyPath défini sous IB. Je ne peux donc pas débinder et rebinder à la main, à moins de recréer toutes les outlets et de stocker tous les keyPaths dans mon code.
Bref, ras le c.. des bindings. >:(
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
J'ai mis longtemps à les adopter, parce que je n'aimais pas l'aspect "formule magique" adjoint, comme tu dis, d'un manque de souplesse dès qu'il s'agit de personnaliser un peu.
Mais petit à petit, je migre vers leur utilisation, parce qu'il y a quand même de nombreux cas simples où justement, leur usage dispense d'une bonne tripotée de "glue code". Le problème des contrôlleurs, c'est qu'il faut s'adapter à eux plutôt que l'inverse, mais au final ça oblige aussi à rester propre sur l'abstraction.
Par contre, je suis plutôt pour l'établissement des bindings dans le code plutôt que dans IB pour plusieurs raisons :
-dans IB, il faut aller les chercher pour les voir; j'aime mieux regrouper ça dans un bloc de code
-si on a des NIB localisés, il faut se taper les modifs des bindings dans tous les NIB (c'est le souvenir que j'en ai; depuis, ça a peut-être évolué avec les outils de refactoring)
-comme tu dis, dans le code on peut désactiver les bindings facilement, même si je n'ai pas encore eu besoin de faire ça.
+
Chacha
Ne serait-ce pas plutôt que les bindings sont perdus dès qu'on copie et colle des vues ?
Sinon, personnellement et pour l'instant, les bindings me plaisent... Je suis plutôt puriste dans ma façon de développer, les boà®tes noires dont on ne connaà®t pas le fonctionnement me font plutôt peur, mais je fais confiance à Apple pour concevoir du code suffisamment bien optimisé pour pas avoir à m'inquiéter des performances.
De plus, en tant que développeur, et surtout développeur objet, pouvoir utiliser des structures déjà conçues pour effectuer des tâches répétitives et donc le code est généralement un copié/collé, les bindings sont un vrais bonheur. ça paraà®t paradoxal mais quand même le but de la programmation (surtout orienté objet) c'est justement de moins avoir à programmer. Plus le code est modulaire et réutilisable mieux c'est.
Donc pour l'instant, personnellement, j'ai encore un peu de boulot avant d'être capable d'appréhender totalement les bindings, envers lesquels j'étais réticent au début, je trouve quelque ineptie qui me dépasse totalement, genre deux liens conçues de la même manière mais qui ne se comportent pas de la même manière... Mais je pense tout de même que les bindings peuvent être très utiles, pas pour tout bien sûr, mais pour beaucoup de choses très répétitives.