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: Graham Cox <email@hidden>
- Date: Thu, 11 Sep 2008 14:33:04 +1000
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