Re: Cocoa newbie app architecture / dialog question
Re: Cocoa newbie app architecture / dialog question
- Subject: Re: Cocoa newbie app architecture / dialog question
- From: Murat Konar <email@hidden>
- Date: Fri, 15 Dec 2006 10:28:00 -0800
Firstly (and perhaps you already know this), you should be using
sheets rather than "modal dialogs" for situations like the one you
describe.
Next, why do you think you need a custom window controller?
_murat
On Dec 14, 2006, at 8:10 PM, John Richetta wrote:
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
_______________________________________________
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