Tour d’horizon d'Objective-C/Cocoa avec SAM
edit: modifié pour pointer vers l'article
Tour d’horizon d'Objective-C/Cocoa avec SAM
edit: modifié pour pointer vers l'article
Je réponds ici pour pas dériver trop dans le post de Spootnik.
Tout a fait, pour prendre le cas des boîtes d'interface, l'ensemble du paramétrage se fait aussi dans un fichier xml plist (écriture d'un simple NSArray). Par exemple, voici à quoi ressemble la définition pour accéder à la propriété "Enable" d'une NSComboBox:Envoyé par Tarul
![]()
On y trouve les champs:
- Name: Le nom généric de l'entrée (utilisé par la suite pour aller chercher la traduction).
- Category: pour le classement lors de l'affichage dans le panneau des propriétés (utilisé par la suite pour aller chercher la traduction).
- ClassName: pour le type d'objet Obj-C supporté par l'entrée.
- Default: no comment.
- Persisiting: indique si une entrée est variable ou constante.
- Target: l'objet à interroger ("View" pour l'objet graphique ou "Plugin" si on a une tâche particulière à faire avant la mise à jour de l'objet graphique).
- Getter: le nom de la méthode d'accès pour récupérer la valeur.
- Setter: le nom de la méthode utilisé pour mettre à jour.
- Type: Si on a besoin d'une transformation en type de base et vice et versa lors de l'appel du getter ou du setter.
A partir de là, on fait un usage intensif des capacités d'introspection d'Objective-C pour vérifier la validité des données et les véhiculer. Après, que ce soit du lard ou du cochon, ce n'est pas un souci.![]()
J'ai tout de même gardé une part d'improvisation pour le fun...Envoyé par Tarul
![]()
![]()
Bonjour,
Je voudrais sortir ce sujet du cimetière pour poser deux questions :
- Est-ce que c'est toi qui fait ce projet ?
- Où est-ce qu'il en est ? Parce que personnellement il m'intéresse beaucoup !
Partager