best practice for sharing NSControllers between window controllers?
best practice for sharing NSControllers between window controllers?
- Subject: best practice for sharing NSControllers between window controllers?
- From: Beau Cronin <email@hidden>
- Date: Wed, 24 Aug 2005 10:53:43 -0400
I have an app which currently has two controller classes, one for
each of two main windows (app window and a rather complex properties
window); let's call them AppController and PropertiesController.
Each of these two windows lives in its own nib file, and each nib
file of course has an instance of the relevant controller. This
being a core data + bindings application, each of these two
controllers/windows has a number of NSController instances which
manage the view contents. So far so good.
For the most part, the NSControllers are specific to the window in
which they live and don't need to be shared. The one exception is
the NSArrayController in my main window which contains my "top-level"
entities (call it Controller A). When the properties window/
controller is invoked, it needs to be able to retrieve Controller
A's current selection. This is where I can see several
possibilities, and I'm wondering if the experts can help me decide
between them:
1) PropertiesController's init function takes an instance of
AppController as an argument, and invokes an appropriate accessor to
retrieve Controller A. PropertiesController can then get the current
selection from Controller A and proceed.
2) PropertiesController's init function takes Controller A itself as
an argument, and then accesses it as above. This is more specific,
but might be less flexible if more communication is necessary between
the two controllers in the future.
3) Having two separate controllers is stupid in this case.
AppController should be set as File's Owner of PropertiesWindow as
well, and then you don't have to worry about this whole thing. (I
don't think this is right, but what do I know?)
4) You're doing something fundamentally wrong with NSControllers,
sonny, and here's what it is.
Any disambiguation, godly pronouncement, or humble suggestions
appreciated.
Also, one more general question. I understand that the controller
layer is, necessarily, the most task-specific and open-ended part of
a Cocoa application and that there are few obvious answers to design
questions which can be given without a careful appraisal. I'm
wondering if there's a good resource for best practices in this area,
however. When is it, on balance, a good idea to break windows into
their own nib files with their own controller classes? How should
different window controllers communicate (e.g., how to share a
managedObjectContext)? What should be shared between them, and what
should they maintain for themselves?
Any pointers to this sort of resource appreciated.
Beau
P.S. An aside: Is it just me, or is the word "controller" pretty
overloaded? It refers to a layer in the MVC pattern, a generic title
of a controller class (as in AppController), and a specific type of
model guardian (as in NSController, NSArrayController, etc.). This
makes writing a post like this one pretty confusing, and I have to
hope that those reading it just "get" what I'm saying based on
experience. Is there a more graceful way of doing this?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden