Dis Osxitan, si Tiff est d'accord, il me semble qu'il faudrait changer le titre de ce sujet "Accesseurs indexés" En effet il n'y a aucun accesseurs indexés dans tout le fil de discussion ::)
"Bindings à la volée" ou "Bindings on the fly" ou encore ""Bindings manuels" me semble plus adapté et se pretera mieux à une recherche ultérieure.
J'allais le dire ! Je voulais faire des recherches sur les accesseurs indexés, Mai sla direction prise a été toute autre. Bindings à la volée n'est pas mal. Bon, puisque mon appli quiNeSertARienSaufAChoisirLeJourDesSphaghetti est terminée, il ne me reste plus qu'à me faire un petit résumé, pour revoir toutes les étapes. Je vais commencer par essayer de me passer des bindings (outlets actions) pour arriver à l'appli "parfaite" . À plus.
Je vais commencer par essayer de me passer des bindings (outlets actions) pour arriver à l'appli "parfaite" . À plus.
Tu veux dire pour arriver à une maitrise parfaite. Parce qu'à mon humble avis l'appli est mieux avec les bindings qu'avec une série d'outlets, et permet mieux une évolution ultérieure également du reste ... bon codage @+
Ben les gars ca donne pas envie de se mettre aux bindings tout ce remue-ménage !!!
Salut Eddy Tu te moques là ?
Au contraire on s'est bien amusés à torturer ses malheureux bindings pour voir ce qu'ils ont dans le ventre ;D Et ils se sont montrés bien coopératifs au bout du compte. Par le binding à la volée nous obtenons une souplesse d'utilisation inexploitée la plupart du temps 8)
Au départ Tiff cherchait à éviter l'usage d'un NSObjectController passerelle (dénomé alias dans certains tuto) et il y a parfaitement réussi en 5 minutes avec 1 ligne de code de binding à la volée ("on the fly"). Nous avons par la suite essayé de pousser au maximum les possibilités offertes par cette méthode du binding à la volée tout en explorant un peu les options offertes. Moralité on est passé d'un binding entièrement établi sous I.B. avec un NSObjectController et un NSArrayController, à un nib dépouillé de tout contrôleur avec des bindings entièrement faits dans le code. Ces 2 extrèmes, ainsi que les étapes intermédiaires, étant parfaitement fonctionnelles. :rose!:
Non non...je me moque pas ::) Tout ceci m'a l'air très intéressant pour vous passionner comme ça. Et des que j'ai un moment pour faire tes tutos ClicCool, je m'y met. Comme ca je pourrais enfin me faire une opinion sur ces bindings
Tu veux dire pour arriver à une maitrise parfaite.
Non non, je pars d'une appli mal fichue (avec outlets et actions) pour petit à petit arriver à une appli parfaite (avec bindings). Le tout pour vérifier que je maà®trise parfaitement, tu as raison.
Je peux encore poser une question ? Pour le lien entre le popup et la fenêtre , ne faudrait-il pas, au sens du MVC, un objectController ? Ce qui permettrait de mettre un superbe NSValueTransformer, qui mettrait par exemple une majuscule au début du nom du jour ?
Tu veux dire pour arriver à une maitrise parfaite.
Non non, je pars d'une appli mal fichue (avec outlets et actions) pour petit à petit arriver à une appli parfaite (avec bindings). Le tout pour vérifier que je maà®trise parfaitement, tu as raison.
C'est la première fois que j'entend quelqu'un dire qu'une appli avec outlets et actions est mal-fichue !!! ??? Tu crois que tu n'exagères pas un peu Tiff ?Â
Tu as donc bindé le champs texte sur le popUp. La saisie dans le champs modifie le popUp en y adjoignant le texte saisi mais ne modifie pas les choix du popUp qui sont gérés par l'arrayController du popUp.
Malheureusement les NSMutableStrings n'ont pas tellement de propriété bindable, et en particulier pas stringValue Pour que les choix du popUp soient édtés par le champs et si on veux rester à la volée, il faut créer des objets mutables ayant une propriété nom par exemple pour représenter les choix et binder alors sur le contrôller avec une clef genre @selection.nom.
La saisie dans le champs modifie le popUp en y adjoignant le texte saisi mais ne modifie pas les choix du popUp qui sont gérés par l'arrayController du popUp.
ça m'est venu à l'idée après avoir vu une doc Apple sur les bindings, et en particulier sur les menus popup dans les tableView où toutes les colonnes sont bindées à des textField. Celle qui a été traduite chez ProjectOmega, je crois (ça date d'avant les vacances !). Il faudrait que je la relise, mais je crois que ça ne modifie que le popup de la ligne sélectionnée, et ça permet à l'utilisateur d'ajouter lui-même un item.
Pour que les choix du popUp soient édtés par le champs et si on veux rester à la volée, il faut créer des objets mutables ayant une propriété nom par exemple pour représenter les choix et binder alors sur le contrôller avec une clef genre @selection.nom
Je vais y réfléchir, mais plus tard. Là je suis retourné dans les outlets-actions. Dur dur, j'ai perdu des réflexes ! :P
Oui ! -1 modulo 7, pourquoi ça ne fait pas 6 ? Un modulo 7 n'accepte en théorie que 7 valeurs (0, 1, 2, 3, 4, 5, 6) pas 13 ! Enfin, je me suis bien amusé.
Réponses
si Tiff est d'accord, il me semble qu'il faudrait changer le titre de ce sujet "Accesseurs indexés"
En effet il n'y a aucun accesseurs indexés dans tout le fil de discussion ::)
"Bindings à la volée" ou "Bindings on the fly" ou encore ""Bindings manuels"
me semble plus adapté et se pretera mieux à une recherche ultérieure.
Bon, puisque mon appli quiNeSertARienSaufAChoisirLeJourDesSphaghetti est terminée, il ne me reste plus qu'à me faire un petit résumé, pour revoir toutes les étapes. Je vais commencer par essayer de me passer des bindings (outlets actions) pour arriver à l'appli "parfaite" .
À plus.
Tu veux dire pour arriver à une maitrise parfaite.
Parce qu'à mon humble avis l'appli est mieux avec les bindings qu'avec une série d'outlets, et permet mieux une évolution ultérieure également du reste ...
bon codage
@+
Non non...je me moque pas ::)
Tout ceci m'a l'air très intéressant pour vous passionner comme ça.
Et des que j'ai un moment pour faire tes tutos ClicCool, je m'y met. Comme ca je pourrais enfin me faire une opinion sur ces bindings
Non non, je pars d'une appli mal fichue (avec outlets et actions) pour petit à petit arriver à une appli parfaite (avec bindings). Le tout pour vérifier que je maà®trise parfaitement, tu as raison.
Je peux encore poser une question ?
Pour le lien entre le popup et la fenêtre , ne faudrait-il pas, au sens du MVC, un objectController ? Ce qui permettrait de mettre un superbe NSValueTransformer, qui mettrait par exemple une majuscule au début du nom du jour ?
O0
Oui oui tu as raison
C'est la première fois que j'entend quelqu'un dire qu'une appli avec outlets et actions est mal-fichue !!! ???
Tu crois que tu n'exagères pas un peu Tiff ?Â
Oui mais de là à dire que les applis conçues sans bindings sont mal-fichues, quand même !
Si ! ;D
8) ;D ;D ;D
[Fichier joint supprimé par l'administrateur]
Tu as donc bindé le champs texte sur le popUp.
La saisie dans le champs modifie le popUp en y adjoignant le texte saisi mais ne modifie pas les choix du popUp qui sont gérés par l'arrayController du popUp.
Malheureusement les NSMutableStrings n'ont pas tellement de propriété bindable, et en particulier pas stringValue
Pour que les choix du popUp soient édtés par le champs et si on veux rester à la volée, il faut créer des objets mutables ayant une propriété nom par exemple pour représenter les choix et binder alors sur le contrôller avec une clef genre @selection.nom.
ça m'est venu à l'idée après avoir vu une doc Apple sur les bindings, et en particulier sur les menus popup dans les tableView où toutes les colonnes sont bindées à des textField. Celle qui a été traduite chez ProjectOmega, je crois (ça date d'avant les vacances !). Il faudrait que je la relise, mais je crois que ça ne modifie que le popup de la ligne sélectionnée, et ça permet à l'utilisateur d'ajouter lui-même un item.
Je vais y réfléchir, mais plus tard. Là je suis retourné dans les outlets-actions. Dur dur, j'ai perdu des réflexes !
:P
[Fichier joint supprimé par l'administrateur]
Homage à Ptits Bras en effetÂ
[EDIT] tu t'es aidé des NSLogs pourtester le modulo et initialiser élégament le jour de la semaine ?
Oui ! -1 modulo 7, pourquoi ça ne fait pas 6 ? Un modulo 7 n'accepte en théorie que 7 valeurs (0, 1, 2, 3, 4, 5, 6) pas 13 ! Enfin, je me suis bien amusé.