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 16:53:32 +1000
On 11 Sep 2008, at 4:16 pm, Seth Willits wrote:
In Photoshop CS2 (which I have), previews are always within the
dialog itself. In that case, it seems logical to me to make a
temporary copy of your model for the dialog to modify and display as
it needs. However, it sounds as if that isn't what you're
describing; You want the controls in the dialog to modify the
visible model in the *document* window.
It may have changed since I last used it much, but they used to have a
local preview in the dialog AND a live preview in the document if you
checked the box.
In that case, then passing settings from your document to the
dialog, and then after the dialog closes grab the settings back into
the document to apply the changes, doesn't make sense to me. It
makes more sense to me for the dialog controller to be given a
reference to the model and that's it. So your document/window
controller/whatever isn't responsible for applying the changes, the
dialog controller is.
Well, I simplified my situation somewhat. In fact I have a small
hierarchy of controllers, because this particular interface is really
pretty complicated. There's a main NSWindowController that is
responsible for the whole dialog, but since that has several tabs, I
decided to use a separate subcontroller for each of them because there
are so many settings in each tab. The main controller does in fact
apply the settings to the data model, but it needs to gather the
settings from the subcontrollers to do so. This also allows me to
reuse the subcontrollers if I decide to split out part of the UI into
a different form later.
From there, your dialog could:
- Make copies of the values of all the settings it can change, let
the user change the model values as much as they want, and then if
the click Cancel, simply apply the saved values, or if they hit
Apply, then just close the window.
Yes, it could save the settings in, oh, I don't know, a dictionary
maybe. That way it doesn't have to declare an ivar for each different
setting, but instead can have a common "settings" ivar and common
utility code to save/restore the values based on a key.
Having done this a few times there's a strong case for generalising
this into a completely reusable class, though I haven't done that at
this stage.
- Keep an undo-like stack of changes and undo them as necessary if
they click Cancel.
Well, I was looking for something *simpler* than what I have now.
Or your model could implement commit grouping itself. The dialog
controller would simply begin a group, the dialog would only ever
set property values in response to actions of the controls, and when
the dialog is closed, either commit or revert the group.
Again, such a "group" could very straightforwardly be contained by a
dictionary. There's no particular reason to use an Undo stack here, as
typically the user doesn't back out settings changes in a dialog one
by one, so the *order* of the changes doesn't need to be preserved,
just the fact that they have changed.
If the controls in the dialog are directly bound to properties of
the model, you'd even save a bunch of code. Then each dialog
controller is nothing more than a nib with a bunch of controls bound
to a model, and essentially three lines of code to begin, commit, or
revert changes.
Well, it's certainly possible (even likely) that bindings changes the
picture considerably. However, for now I'm not using bindings because
learning the ins and outs of them is going to slow me down and I'm on
a ridiculous schedule as it is. So for now I'm much faster doing
things the old-fashioned way. I have a bunch of utility methods in a
category on NSMutableDictionary that allows me to get/set most UI
states with one line of code, so at present every action has one line,
and every "setter" to set the initial UI state from the settings is
one line.
It's taken me until to even quite understand what you're asking.
Hopefully this helps or triggers a thought. :-)
Sure, and I appreciate you taking an interest. Discussing it certainly
helps me focus on what I'm doing.
cheers, Graham
_______________________________________________
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