Cocoa newbie app architecture / dialog question
Cocoa newbie app architecture / dialog question
- Subject: Cocoa newbie app architecture / dialog question
- From: John Richetta <email@hidden>
- Date: Thu, 14 Dec 2006 20:10:05 -0800 (GMT-08:00)
I have a basic question about correct relationships in my code. I have an application that supports multiple documents (one window per document). Each document can potentially open its own copy of a modal dialog ("panel"), that operates on the contents of that document. I'm trying to understand who ought properly create the (custom) window controller associated with the dialog.
One way to do this is to place a reference to the dialog window controller in the NIB file that defines the document window (that is, add a dialog window controller outlet to the document). This gives each document its own window controller (and makes use of the generally very useful and helpful "reconstitution from NIB" facilities).
But, this has some drawbacks, it would seem. First, in general, it appears that window controllers are largely reusable, in the sense that they maintain relationships, more than data. They do, critically however, each maintain a reference to a window, which presumably cannot be shared in my case. So, pretty certainly, each document window needs a different dialog window controller.
Another problem is even more basic. If I define the main document window in NIB X, and then desire to place my dialog definition in NIB Y, how can NIB X refer to NIB Y? This is necessary if I want to do as outlined above, and give the document a reference to the dialog window controller. Note that moving the dialog definition to the document window NIB is at best unwieldy. Generally, it appears to require additional nonstandard window controller code, as well, since the standard window controller appears to assume that the file's owner is set to the window controller, at the time the window controller's window is being constructed. This won't be the case if the dialog window is moved into the document window NIB. Of course, putting dialogs in document NIBs is undesirable from an organizational standpoint.
Yet another problem is that if I use this scheme, the dialog so instantiated is always instantiated immediately upon creation of a new document. This seems like it should be done lazily - that is, when the dialog is actually invoked. This can be achieved if I programmatically create the dialog window controller reference, in the document. In this case, it appears that the request to display such a dialog should be routed directly to the document (not, for example, an app delegate), since, again, the dialog being created is window specific.
If I give the responsibility for creating the dialog window controller to the main document, then I can defer creation of this window controller (and potentially many other similarly used dialog controllers!) until it's actually needed. This works so far, but seems to get the document involved in details of managing the dialog window controller(s) that do not seem to be assigned to documents in any other examples I've looked at, and which generally seem somewhat out of place (dialogs have nothing to do with document model management). But I haven't so far found a good example that matches my case exactly, even though I would expect this case to be pretty common.
As I understand the roles of the application and document classes, there doesn't appear to be another great place to put this functionality, though possibly the document controller is a reasonable choice. I don't think it will resolve all these issues, however.
I'm obviously somewhat confused. Is it obvious where to place this responsibility? Would someone point me in the right direction, or to some documentation I missed? Enlightenment greatly appreciated.
-jar
P.S. - If I have any complaint about Cocoa, it is that the many "controller" classes seem to be fairly loosely defined. They seem to be something of a catch-all for anything deemed "application specific," and this seems to dissuade (although not preclude) factoring out functionality that probably should be factored out (a case in point might be the relatively recent arrival of bindings?). I'm not trying to start a flame war; perhaps as my understanding improves, the various controllers will become more distinct.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden