›

NSViewController, representedObject et KVO sur les dépendances ?

yoannyoann Membre
dans API AppKit #1
Salut la compagnie,



Je me heurte à  un problème tout con, tellement con que je ne vois pas la solution...



Toujours dans mon application de gestion serveur, j'ai fini de refaire mon architecture pour quelque chose d'intéressant, maintenant mon code est correctement réutilisable et je peux changer la forme de mon interface d'admin entre mono tool / multi tool très simplement.



Pour me simplifier la vie, chaque module travail avec des NSViewController et disposent de l'objet à  représenter via la propriété representedObject, ma vue est relié au modèle directement via bindings, le truc classique. Coté fonctionnalité, tout est OK, l'application est fonctionnelle et j'ai divisé par deux le nombre de ligne de code spécifique à  l'application.



Il me reste qu'un truc très très con à  gérer... Le dirty state de mon document... Comment savoir quand le contenu est modifié ?



Absolument toute les éditions passent par les bindings, je n'ai aucune méthode où je pourrais rajouter un changement d'état...



J'ai bien pensé au KVO mais observer representedObject ne permet pas d'être notifier des éléments inclus... (Et vu la taille de l'arbre de valeurs, je ne vais pas rajouter un KVO pour chaque...).





Quelqu'un aurait une bonne idée ?

Réponses

  • BaardeBaarde Membre
    #2
    Si tu utilises un NSDocument et que les changements sont enregistrés dans le undoManager de celui-ci, c'est automatique.
  • yoannyoann Membre
    #3
    'Baarde' a écrit:


    Si tu utilises un NSDocument et que les changements sont enregistrés dans le undoManager de celui-ci, c'est automatique.




    Je n'utilise pas de NSDocument... Mon modèle est simplifié au max en fait.



    J'ai un NSWindowController comme coquille vide, un NSDocument qui représente les informations de connexion serveur et va créer un objet custom, à  base de NSObject qui va contenir un dico de settings comme base de travail ainsi que des méthodes interne de mise en forme des réglage.



    Mon NSWindowController va demander à  ce customObject la sous classe de NSViewController à  instancier pour travailler.



    Lorsque cette NSViewController est créé, mon customObject lui est passé en representedObject et le reste travail entièrement en Bidings...



    D'après toi Nico, si je remplace mon representedObject par le NSDocument (qui dispose d'une propriété vers le customObject), ça va le faire tout seul ? Le bindings passant à  ce moment par le document pour accéder à  mon modèle.
  • CéroceCéroce Membre, Modérateur
    #4
    Non, c'est pas ce qu'il dit.

    Si tu utilises le NSUndoManager (ça peut être celui du NSDocument, ou un que tu crées toi-même), celui-ci sait forcément s'il y a eu des modifs puisque tu lui fais enregistrer chaque action pour éventuellement l'annuler.



    Je n'ai pas trop le temps de fouiller dans la doc, mais regarde aussi si tu ne peux pas utiliser la méthode de NSKeyValueObserving + (NSSet *)keyPathsForValuesAffectingValueForKey:(NSString *)key.

    Tu pourrais ainsi rendre une variable ("modified") dépendante des modifs sur les autres clefs.
  • yoannyoann Membre
    #5
    keyPathsForValuesAffectingValueForKey peut être une bonne solution de secourt, mais je suis quand même obliger de hardcoder les informations de bindings...



    Je comprends pas qu'on ne puisse pas naturellement être informer du changement de valeur sur tout l'arbre d'un NSDictionary...





    Concernant les NSUndoManager, je n'en utilise pas... Il faudrait que je regarde comment les intégrer aux bindings... J'ai tellement de réglage à  exposer que je veux vraiment tout passe en bindings sinon c'est la misère...
  • yoannyoann Membre
    #6
    J'ai peut être un truc à  tenter avec les NSObjectController...
  • yoannyoann Membre
    #7
    Bon c'est pas mieux avec NSObjectController... Le KVO ne reste qu'à  un seul niveau. Je pensais que cet objet fournirais le support du UndoManager mais en fait non...



    Et c'est pas dit que le NSDocument apporte quoi que ce soit puisque même en passant par lui, ce n'est pas une de ses propriétés qui sera édité...
  • BaardeBaarde Membre
    #8
    'yoann' a écrit:


    Je comprends pas qu'on ne puisse pas naturellement être informer du changement de valeur sur tout l'arbre d'un NSDictionary...


    À moins de surcharger -[NSObject setValue:forKeyPath:] image/wink.png' class='bbc_emoticon' alt=';)' />
  • yoannyoann Membre
    #9
    'Baarde' a écrit:


    À moins de surcharger -[NSObject setValue:forKeyPath:] image/wink.png' class='bbc_emoticon' alt=';)' />




    C'est ce que j'ai fait au final, au niveau de NSObjectController par contre.
Connectez-vous ou Inscrivez-vous pour répondre.