Mehrere nibs + controller + bindings

  • Mehrere nibs + controller + bindings

    Hallo,

    in meiner Anwendung ist es recht unübersichtlich. Fast alles ist in einer nib untergebracht.

    Habe viele Fenster, Views, Controller (NSArrayController) und Bindings, die ich über den IB definiert habe.

    Wie stelle ich es nun am geschicktesten an, dass ich das Ganze auf mehrere nibs verteilen kann, ohne dass ich die fähigkeit verliere die Bindings im IB definieren zu können - falls sich der Controller, auf den das binding zugreift in einer anderen nib befindet.

    Folgendes wäre ein denkbarer Weg:

    Zwei Nibs A und B. Nib A enthält einige NSArrayController, die auch B kennen soll. In B legt man im IB die NSArrayController "pseudoinstanzen" an, die man benötigt. Im Controller von B fügt man methoden zu, die erlauben die NSArrayController in B, welche als Outlets im Controller von B verfügbar sind zu setzen. Der Controller von A erzeugt dann den Controller von B und ruft B's methoden auf, um die als outlets verfügbare NSArrayController zu setzen.

    Ist das ein empfehlenswerter weg?

    Was auch denkbar wäre: NSApp kennt alle NSArrayController. Die Controller der Nib files holen sich selbst durch [[NSApp delegate] einNSArrayControllerDenIchBenötige] die Zeige zu den ArrayControllern selbst.

    Die Controller haben Outlets wie:

    IBOutlet NSArrayController *einControllerDenIchBaldKennenWerde;

    Im IB ist der NSArrayController angelegt aber er hat noch alle Standardwerte.

    Beim Laden der nib setzt dann der arraycontroller das outlet.

    Quellcode

    1. [self setEinControllerDenIchBaldKennenWerde:[[NSApp delegate] einControllerDenIchBaldKennenWerde];


    Oder wie macht ihr sowas?

    Bindings zur laufzeit will ich vermeiden...
    Die Objective-Cloud ist fertig wenn sie fertig ist. Beta heißt Beta.

    Objective-C und Cocoa Band 2: Fortgeschrittene
    Cocoa/Objective-C Seminare von [co coa:ding].
  • Ich bin zwar kein Experte für Bindings aber ich glaube mich zu erinnern daß Apple in der Doku die dynamischen Bindings für genau diesen Fall vorschlägt.

    Ich denke man sollte genau Controller und Views in eine NIB zusammenfassen, die eine bestimmte Bedeutung und möglichst viel Bezug zueinander haben. Und idealerweise genau 1 Hauptfenster pro NIB.

    Und die Kommunikation sollte idealerweise überhaupt nicht zwischen den Controllern verschiedener NIBs laufen sondern über das gemeinsame Datenmodell. Wenn man also ein (i)-Fenster aufmacht, dann lädt es alle Controller und hängt sich an die Daten so an wie es das (i)-Fenster braucht. Und wenn man zwei (i)-Fenster haben will lädt man die NIB einfach nochmal.

    -- hns
  • Ach - das ist doch aber alles nicht wirklich optimal. In einem anderen Thread wurde erörtert, dass es keinen Grund - außer eben der Übersichtlichkeit wegen - mehrere Nibs zu erzeugen.

    Der IB müsste einfach nur mit vielen Objekten so gut umgehen können wie mit wenigen. Aber lassen wir dieses rumgejammere.
    Die Objective-Cloud ist fertig wenn sie fertig ist. Beta heißt Beta.

    Objective-C und Cocoa Band 2: Fortgeschrittene
    Cocoa/Objective-C Seminare von [co coa:ding].
  • Hier habe ich das erläutert:
    osxentwicklerforum.de/wiki/ind…gs_.C3.BCber_mehrere_Nibs

    Wie du siehst, ist es ganz einfach.

    Es kann auch sinnvoll sein, von Controller zu Controller über mehrere NIBs zu binden, wie du das in einem Nib machen würdest. Die Unterschiede habe ich im Artikel skizziert. Es ist eiinffach etwas anderes.

    Apple empfiehlt mehrere NIBs, um Speicher zu sparen. Ich würde mich daran halten.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?