Frage zu WindowController ohne Document based App.

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Frage zu WindowController ohne Document based App.

    Hi. :)

    Nachdem ich das Buch nun einmal komplett durchgeackert habe, sowie das meiste noch ein zweites Mal (Mit etwas mehr Hintergrundwissen versteht man manche Passagen eben doch besser. ;)),
    wollte ich mich an ein erstes eigenes Testprojekt machen.


    Das Ganze soll ein Core-Data Projekt werden, jedoch nicht Document based.


    Um mir gleich die richtigen Struktur anzugewöhnen wollte ich das Hauptfenster aus MainMenu.xib herausnehmen, und in ein eigenes File packen.
    Dazu dann eben einen WindowController.

    Aber so ganz sicher bin ich mir über den Aufbau im Moment noch nicht...

    Geladen wird das Window beim Start vom AppDelegate.
    Der WC ist File's Owner vom Window NIB, window und delegate outlets zwischen WC und Window stehen.

    So weit so gut. Das Fenster erscheint wie es soll, Delegate Methoden im WC werden brav ausgeführt.


    Nur, wie komme ich nun an mein AppDelegate und somit an meine Core-Data Geschichten?
    Wenn man ein neues Projekt CoreData/ohne Document based erstellt, hat man ja Fenster und AppDelegate im gleichen NIB.

    Bei einem Document based konnte ich dagegen über die Document Eigenschaft an Core-Data ran.

    Muss ich eine weitere Instanz des App-Delegates im Interface Builder in mein Window-Nib ziehen, oder gibt es einen eleganteren Weg?

  • RE: Frage zu WindowController ohne Document based App.

    Hi! :)

    Original von Tobse001
    Das Ganze soll ein Core-Data Projekt werden, jedoch nicht Document based.

    Dürfte ja kein Problem sein. :)

    Original von Tobse001
    Um mir gleich die richtigen Struktur anzugewöhnen wollte ich das Hauptfenster aus MainMenu.xib herausnehmen, und in ein eigenes File packen.

    Was? Wozu in Gottes Namen denn das?

    Original von Tobse001
    Muss ich eine weitere Instanz des App-Delegates im Interface Builder in mein Window-Nib ziehen, oder gibt es einen eleganteren Weg?

    Der elegante Weg ist, Hauptfenster und Hauptmenü zusammen in der MainMenu.xib zu lassen. Du hast keine dokumentbasierte Anwendung, insofern ist die Trennung von Hauptfenster und Hauptmenü sinnlos.
    Und schon bist du auch dein Problem (fürs Erste) los. :)

    Das Eine kann eh nicht lange ohne das Andere existieren bzw. ist die Funktionalität dann sehr eingeschränkt. Das Hauptmenü wird immer geladen, das Hauptfenster ebenfalls. Beide sind fest verknüpft und du kannst nicht mehr als ein Hauptfenster haben. Ausgelagert werden im Allgemeinen nur Zusatzfenster, zum Beispiel für Detailansichten, Einstellungen und so weiter. Also Fenster, die man nicht dringend direkt beim Start der Anwendung braucht.
    Wenn du das Hauptfenster aus irgendwelchen Gründen wechselnd haben willst, dann nimm eine Document Based Application. Du würdest sonst nur versuchen sie nachzubauen, das klappt nicht.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Danke für die schnelle Antwort. :)

    Ich hab das wohl mit dem "Jedem Fenster seinen WindowController & NIB" wohl etwas zu ernst genommen, bezogen auf das Hauptfenster der App. ;)

    Schenkt man sich dann normal den WindowController komplett für das Hauptfenster?
    Oder erstellt man besser dennoch einen. für die Funktionen die eben das Fenster angehen (zwecks Ordnung).

    Dabei würde sich folgender Knoten in meinem Hirn bilden:
    Im Buch wurde es ja immer so beschrieben, dass der WC dann auch als File's Owner gesetzt wurde.
    Wäre dies hier denn richtig, da das MainMenu ja auch im NIB liegt, und nicht fest zu dem einen Fenster gehört?

  • Ich hab für jedes Fenster einen Controller, also würde ich mir den nicht schenken.
    Das ist aber Geschmackssache. :)

    Du hast doch nur ein einziges Fenster und kannst nur eine einzige Datei zur Zeit bearbeiten. Wenn ich den File's Owner richtig verstanden habe, dann löst der dynamisch auf, welche Datei gerade in Bearbeitung ist. Das sollte deine Document Based Application schon wissen, auch das Fenster der Application bzw. sein Controller.
    Aber du hast hier nur ein Hauptfenster mit einer Datei offen. Da ändert sich nix spontan durch rumklicken, insofern sehe ich keinen Grund für den Einsatz als File's Owner.

    Die Konzepte einer Anwendung und einer dokumentbasierten Anwendung sind halt grundverschieden.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Original von Lucas de Vil
    Die Konzepte einer Anwendung und einer dokumentbasierten Anwendung sind halt grundverschieden.


    Ja, das ist es was mich auf meinen ersten Schritten gerade auch etwas aus der Bahn wirft. ;)

    Sowohl im Buch von Amin, als auch im Hillegass sind die komplexeren Beispiele die WCs einsetzen Document based.
    Und so bin ich schon ins stolpern geraten bevor ich überhaupt ein Grundgerüst für ein Programm hatte...

    Werde also dem Window einen Controller spendieren, ohne ihn zum Files-Owner zu machen.
    Bedeuted dann, dass ich den WC als neues Object in mein NIB ziehen muss, da ich ja (im Gegensatz zur Lösung mit dem Files Owner) sonst keine Verbindungen im IB von/zu ihm machen kann, oder?

    Sorry für die vielen Fragen, aber im Gegensatz zu speziellen Fragen zu bestimmten Methoden/Klassen,
    ist das Googeln bei solch grundlegenden Zusammenhängen meist nicht sonderlich erfolgreich :-/

    Aber wenn das nun so passt sollte ich mich ja endlich mal dem eigentlichen Programm widmen können. :)

    Danke auf alle Fälle so weit.

  • Original von Tobse001
    Sorry für die vielen Fragen, aber im Gegensatz zu speziellen Fragen zu bestimmten Methoden/Klassen,
    ist das Googeln bei solch grundlegenden Zusammenhängen meist nicht sonderlich erfolgreich :-/

    Macht ja nix. :)

    Original von Tobse001
    Bedeuted dann, dass ich den WC als neues Object in mein NIB ziehen muss, da ich ja (im Gegensatz zur Lösung mit dem Files Owner) sonst keine Verbindungen im IB von/zu ihm machen kann, oder?

    Genau das. Die Verbindung müsste übers Delegate laufen.
    Im Übrigen musst du dir auch noch ein Application Delegate erstellen, da du ja keine vorgefertigte MyDocument-Klasse hast. ;)
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Original von Tobse001
    Danke für die schnelle Antwort. :)

    Ich hab das wohl mit dem "Jedem Fenster seinen WindowController & NIB" wohl etwas zu ernst genommen, bezogen auf das Hauptfenster der App. ;)

    Schenkt man sich dann normal den WindowController komplett für das Hauptfenster?
    Oder erstellt man besser dennoch einen. für die Funktionen die eben das Fenster angehen (zwecks Ordnung).

    Dabei würde sich folgender Knoten in meinem Hirn bilden:
    Im Buch wurde es ja immer so beschrieben, dass der WC dann auch als File's Owner gesetzt wurde.
    Wäre dies hier denn richtig, da das MainMenu ja auch im NIB liegt, und nicht fest zu dem einen Fenster gehört?

    Du hast das nicht falsch verstanden, sondern genau so, wie ich es gemeint habe. Du sollst schon für jedes Fenster, auch für das App-Fenster einen eigenen Nib haben. Das hat nichts damit zu tun, dass der Nib dann auf einfache Weise mehrfach zu instantieren ist, sondern damit, dass es besser funktional kapselt.

    Mit dem Argument, dass er ja ohnehin nur einfach existiert und damit in einem Nib liegen kann, könnte man auch argumentieren, dass man nur einen Singleton für alle Klassen hat, weil die ja ohnehin nur einmal existieren.

    Du solltest allerdings dann einen eigenen Controller nehmen, da sonst die Trennung ja sinnfrei wird. In diesen Controller steckt du dann die Funktionalität, die Fensterbezug hat (Resizing, Toolbar-Handling …). Wenn bei dir am Ende doch wieder alles in AppDelegate landet, kannst du es dir in der Tat sparen.
    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"?

  • Ok, also dann versuche ich mich doch nochmal daran wie ganz am Anfang:

    Wir hätten dann MainMenu.nib
    - File's Owner = Application
    - AppDelegate ist hier als Objekt im NIB und bringt
    a) den Zugriff auf Core Data (Model, Store, Context…)
    b) die Methoden für die Menubar, da das Menü App-weit ist.
    c) ist Delegate von Application

    MainWindow.nib
    - File's Downer ist mein MainWC
    - Delegate und Window Verbindungen zwischen File's Downer und dem Fenster sind gesetzt
    - Main WC enthält dann eben die Fenster-spezifischen Dinge + die Delegate Funktionen des Fensters.


    Wäre das richtig so?


    Um im MainWindow.nib auf meine Entitäten zuzugreifen, habe ich über Doku & Google noch den folgenden Weg gefunden:
    NSApplication --> Shared Application --> Delegate

    Womit ich ja einen keypath für einen BindingsController hinbekommen sollte ohne AppDelegate nochmals als extra Objekt in das MainWindow.nib zu setzen.

  • Original von Tobse001
    Ok, also dann versuche ich mich doch nochmal daran wie ganz am Anfang:

    Wir hätten dann MainMenu.nib
    - File's Owner = Application
    - AppDelegate ist hier als Objekt im NIB und bringt
    a) den Zugriff auf Core Data (Model, Store, Context…)
    b) die Methoden für die Menubar, da das Menü App-weit ist.
    c) ist Delegate von Application

    MainWindow.nib
    - File's Downer ist mein MainWC
    - Delegate und Window Verbindungen zwischen File's Downer und dem Fenster sind gesetzt
    - Main WC enthält dann eben die Fenster-spezifischen Dinge + die Delegate Funktionen des Fensters.


    Wäre das richtig so?

    Um im MainWindow.nib auf meine Entitäten zuzugreifen, habe ich über Doku & Google noch den folgenden Weg gefunden:
    NSApplication --> Shared Application --> Delegate

    Womit ich ja einen keypath für einen BindingsController hinbekommen sollte ohne AppDelegate nochmals als extra Objekt in das MainWindow.nib zu setzen.

    Das sieht gut aus.

    NSApplication kannst du einfach im Bindings-Pane des Inspectors auswählen. Das sollte im Buch für DBA (ist ja dasselbe Problem, dass du getrennte Nibs hast) beim Inspector stehen.
    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"?

  • Hallo an alle,

    ich stehe gerade vor einem ähnlichen Problem wie Tobse001. Ich habe mir jetzt zum Üben ein ganz einfaches Interface gebastelt und scheitere schon daran (Sorry, bin Anfänger.. ;) ). Meine "Anwendung" ist ein einfaches Fenster mit einem Button, der ein anderes Fenster öffnen soll. In diesem befindet sich nur ein Button, der es wieder schließt. Ich bin gerade am Verzweifeln, wie ich das korrekt mache..
    Hier mein Gedankengang:
    Im MainWindowWC habe ich die Action für den Button zum Öffnen des zweiten Fensters. Bei den Document-Based-Apps (in CompanyCD) wurde dann ein Selektor in MyDocument aufgerufen. Und in MyDocument gab es dann den Aufruf [self addWindowController: wc]. Nach meinem Verständnis müsste ich so was in der Art ja nun in der Application machen (bzw. im App Delegate, oder?!?), weil ich ja kein Dokument habe. Nur für NSApplication gibt es ja addWindowController gar nicht..

    Ich hoffe, ihr könnt mir weiterhelfen. Vielen Dank schon mal.

    Gruß Alex