Re: How do people typically implement dialog controllers?
Re: How do people typically implement dialog controllers?
- Subject: Re: How do people typically implement dialog controllers?
- From: Boyd Collier <email@hidden>
- Date: Sat, 13 Sep 2008 10:22:24 -0700
I'm rather late coming into this discussion, but Graham's question
addresses something that I puzzled over when, not too long ago, I
started using Cocoa. As a newcomer wanting to avoid learning all
about bindings, the approach I've taken is essentially the same as is
summarized by Graham. It works so well for me that I've still not
invested in trying to find a better way.
Boyd
On Sep 10, 2008, at 9:33 PM, Graham Cox wrote:
Judging by a few replies I've had off-list, I guess I ought to make
this a bit clearer.
I know about the standard NSWindowController model and I'm using it
in the normal way. Also, this discussion probably pertains more
commonly to modal rather than modeless dialogs though I don't use
many modal dialogs and in fact the same technique works fine in the
modeless case also.
For a panel that is an inspector and directly alters the data model,
there's clearly no need for an intermediate dictionary - the actions
can just call through to the data model directly. However there are
other circumstances (especially with modal dialogs, but also
sometimes with modeless ones) where you want to preview the changes
live in your data model, but allow the user to back out using Cancel
or by deliberately committing the changes via Apply. In those cases,
I have found that gathering the dialog settings into a dictionary is
very useful, because I can simply copy the original settings
dictionary and pass that back on a cancel, or pass the edited one on
Apply.
The further benefits of the dictionary are that much of the dialog
controller code becomes very boilerplate, seeing as it is really
just copying settings from controls into a dictionary and vice
versa. Of course there's still the need for someone, somewhere to
move the data from the dictionary to data model and back, but that
can be the data model itself in many cases. It also means that the
"connection" between data model and dialog controller are simplified
- one message to get the settings dictionary and another to set it.
An analogy might be using a parameter block structure to pass
settings data around versus using a whole heap of separate
functions, one for each setting.
So my question becomes: a) is using this intermediate dictionary a
sensible idea?
b) do others typically do this?
c) or is there a better way?
On 11 Sep 2008, at 12:48 pm, Graham Cox wrote:
OK, this is bit of a nebulous question, but I'm curious to know how
people are typically implementing controllers for dialog panels. I
don't mean the nuts and bolts of wiring up outlets to widgets and
implementing actions, but rather the further problem of managing
all the various bits of data. (i.e. the interface between the data
model and the controller). Let's assume we are talking about a
traditional non-bindings, non core-data model but where there are a
substantial number of related settings.
What I find I'm doing is collecting all the settings into a
dictionary, so effectively the dialog is an editor for that
dictionary. At some point the controller defers to a delegate
within the data model (or perhaps another controller) to get the
dictionary from the d/m when the dialog is loaded, and send a
modified copy of the dictionary back to the d/m when the dialog is
OK'd. This is handy in some ways - it makes implementing Cancel or
Apply trivial for example, and I have a bunch of dictionary
utilities that streamline the setting/getting of its values
directly from UI controls.
But I do wonder if this is the most efficient way to do this, and
whether I haven't missed something more obvious.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please 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)
Please 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