On 28 Jan 2009, at 12:10 pm, Jerry Krinock wrote:
Does anyone have an idiom or way of appreciating this problem which
does not produce such spaghetti and headaches?
I think the best way is to accept that you need to handle many
operations in two parts - one that starts it and another that
completes it. This approach works whether any intervening dialog is
app modal, document modal, or not involved at all.
So by factoring your code thus:
- (void) userAction:(id) sender
{
[self theMethodThatReallyDoesTheWork];
}
- (void) theMethodThatReallyDoesTheWork
{
/* .... whatever .... */
}
You can easily insert user confirmation into the userAction part of
the call stack. The 'methodThatReallyDoesTheWork' can be called from a
completion method or directly as you wish. You could pass the selector
of the method to call on completion through the dialog or alert using
the contextInfo parameter and re-use the same completion routine for
all similar alerts.
If the intervening dialog is more complicated than just go ahead or
cancel, the delegate pattern together with a separate controller for
the dialog will keep the code very clean. Dictionaries can be a good
way to encapsulate a lot of settings together so the dialog just edits
the dictionary and the delegate is called with the final dictionary
when OK is clicked (for modal dialogs).
Also, on a general point you want to avoid too many nested dialogs -
ideally you would never nest them though occasionally it's
unavoidable. Trains of dialogs are very user-hostile. One big dialog
with all the necessary settings is preferable, IMO.
--Graham
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
