Remplir un NSArrayController avec un formulaire et coreData
Flo
Membre
Bonjour à tous,
En premier lieu, je tiens à témoigner de mon admiration en ce qui concerne la richesse de ce site et de ses membres. Sa fait plaisir de savoir qu'il existe en France une véritable communauté du développement sous mac os x.
Voila mon problème, j'ai découvert récemment cocoa, la magie du "Key value binding", et coreData. Je suis actuellement sur une petite application de gestion de valeurs boursières utilisant les bindings et coreData. J'ai créé un CustomArrayContoller(Sous-classe de NSArrayContoller) qui rajoute les comportements suivants:
- ouverture d'une sheet d'alerte de confirmation lors de la suppression de données
- ouverture d'une sheet de saisie des champs lors de l'ajout
Mon problème concerne la deuxième option, je n'arrive pas à faire en sorte que l'entité ajoutée au CustomArrayController ai ses champs remplis avec les valeurs fournies par l'utilisateur dans la sheet de saisie...
Des idées ou suggestions?
Merci d'avance pour toutes les réponses que vous pourrez m'apporter et encore bravo pour cet effort de vulgarisation essentiel pour les gens qui, comme moi, se décourage un peu vite devant un pdf de 700 et quelques pages rédigé en anglais.
En premier lieu, je tiens à témoigner de mon admiration en ce qui concerne la richesse de ce site et de ses membres. Sa fait plaisir de savoir qu'il existe en France une véritable communauté du développement sous mac os x.
Voila mon problème, j'ai découvert récemment cocoa, la magie du "Key value binding", et coreData. Je suis actuellement sur une petite application de gestion de valeurs boursières utilisant les bindings et coreData. J'ai créé un CustomArrayContoller(Sous-classe de NSArrayContoller) qui rajoute les comportements suivants:
- ouverture d'une sheet d'alerte de confirmation lors de la suppression de données
- ouverture d'une sheet de saisie des champs lors de l'ajout
Mon problème concerne la deuxième option, je n'arrive pas à faire en sorte que l'entité ajoutée au CustomArrayController ai ses champs remplis avec les valeurs fournies par l'utilisateur dans la sheet de saisie...
Des idées ou suggestions?
Merci d'avance pour toutes les réponses que vous pourrez m'apporter et encore bravo pour cet effort de vulgarisation essentiel pour les gens qui, comme moi, se décourage un peu vite devant un pdf de 700 et quelques pages rédigé en anglais.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
En tout cas, bienvenue à toi. Tu offres ta tournée générale ?
Merci pour ton aide, je n'avais pas pensé à redéfinir la methode newObject de NSArrayController, c'est une piste que je compte bien exploiter.
En attendant, tournée générale :
:fouf):
Merci d'avance...
Donc le principe c'est d'utiliser des outlets dans une classe controleur et de référencer les objets... Si tu as plusieurs objets de même type utilise des NSMatrix, dans IB il suffit "d'agrandir" des contrôles en restant appuyer sur la touche Option (ALT) et ça t'ajoute des contrôles du même type. Tu n'as que la NSMatrix a référencé, et tu accèdes à chaque élément en utilisant leurs "tags".
C'est pour sa que je cherche une autre méthode pour accéder au contenu d'un NSPanel que la traditionnelle utilisation des outlets par connexion sous IB.
Le but est de diminuer l'effort de la personne qui reprends la classe en n'ayant pas à bidouiller sous IB...
J'ai peur que ce système ne fasse qu'empirer la situation. L'utilisation des IBOutlet permet l'identification rapide des différents objets. Si, par exemple, plusieurs objets appellent la même action, savoir lequel a envoyé le message est simple, il suffit de comparer l'adresse du sender et l'adresse de l'IBOutlet et ainsi savoir comment réagir. La comparaison d'adresse mémoire est une technique simple, extrêmement rapide et efficace.
Ce que tu proposes permettrait, si j'ai bien compris, de référencer tous les contrôles d'une même fenêtre dans une collection et d'y accéder en utilisant une clé ou un index... C'est extrêmement coûteux comme opération, et ça n'arrange rien du côté de la programmation.
Si tu utilises un dictionnaire, il faut que l'utilisateur s'assure qu'il utilise la bonne clé, en général quand on utilise un dictionnaire on crée des clés sous forme de NSString globale pour permettre au compilateur de vérifier qu'on utilise des clés existantes. Mais dans le cas de ton dictionnaire, tu les mets où les clés ? Tu vas utiliser des clés définies dans IB par l'utilisateur ? Là , aucune vérification ne pourra être faite, et les erreurs risquent d'être fréquentes, et ça allongera le temps de débogage.
Si tu utilises un tableau, style NSArray, là aussi ça posera problème, comment connaà®tre l'index de l'élément qu'on veut atteindre ? Si tu veux fouiller dans la Content View de ta fenêtre et référencer toutes les sous-vues pour les mettre dans ton tableau... Comment t'assurer que l'ordre de référencement soit toujours le même ? Il faut se rappeler qu'au chargement du NIB, Cocoa reconstruit toute les liaisons entre les vues et sous-vues, entre les différents delegates et IBOutlets contenus dans le fichier... Rien ne garantit l'ordre dans lequel seront indexés tes éléments, dans le pire des cas tu n'auras jamais le même index pour chaque objet... Et ça demandera encore des vérifications...
Donc, non je ne pense pas que ce soit une très bonne idée, les IBOutlets ont cet avantage d'être simple à utiliser, ils assurent aussi que chaque objet soit toujours référencer au même endroit...
Mais sinon, si tu veux vraiment essayer, il suffit de récupérer la content view de tes fenêtres puis de référencer chaque sous-vues...
Tant pis, je vais laisser l'utilisateur se débrouiller en donnant une référence à ses controls via IB. ::)
C'est vrai que sa simplifie la tache même si c'est un peu moins "automatique" que je l'espérais...
En tous cas, merci pour ton aide.