Re: Toolbar code in separate Controller?
Re: Toolbar code in separate Controller?
- Subject: Re: Toolbar code in separate Controller?
- From: Graham Cox <email@hidden>
- Date: Wed, 16 Jul 2008 00:08:35 +1000
I should be careful about claiming what I told you and then posting
code that definitely did *NOT* come from me.
What on earth is a delegator? Do you mean 'delegate'? I believe that
is the terminology I used, and with good reason - it's the normal
jargon for this design pattern (not just on Cocoa and Obj-C but most
other languages too). In normal English, a 'delegator' would be one
who delegates. That's not what the object is in this case, it's the
delegate - the one who is delegated *TO*. I strongly advise you stick
to convention because persisting with your own non-standard
terminology will make your code difficult for others to understand,
and will impede your own understanding of standard concepts in the
long run.
In this case, the target object is quite definitely the delegate. If
you think otherwise, you have missed something.
I also advised you to name your methods to be self-describing.
Somewhere you seem to have gone backwards.
What I actually suggested was:
- (void) showSheetOnParentWindow:(NSWindow*) parent withDescription:
(NSString*) msg delegate:(id) target contextInfo:(void*) contextInfo;
and
- (void) proceedWithReturnCode:(int) returnCode contextInfo:(void*)
contextInfo;
which is intended to be self-describing, and eliminates implied
implementations in one controller being exposed in the other. That's
why my callback quite deliberately does not mention sheets! Ideally
the other method shouldn't mention them either - I slipped up there.
Good method naming is not always easy, but some thought should be put
into it. A good method name almost doesn't require documenting - it
tells you what it does and what its parameters mean.
Graham
On 15 Jul 2008, at 11:13 pm, John Love wrote:
Graham Cox "crammed" down me a lot of info about isolating the
SheetController(delegate) from the calling Controller, the
delegat*or*; for example, keeping the GUI data isolated within the
SheetController and away from the delegator. I also learned about
anonymous callback id pointers that allowed me to create a separate
Controller for calling sheets. My delegator, FileController, called
my separate SheetController via the latter's ShowSheet method. I
passed *self* from FileController as the delegator to ShowSheet,
within which the passed delegator was typed as an anonymous id at
the top of SheetController's implementation file.
- (void) showSheet:(NSWindow*)parentWindow
delegator:(id)theDelegator
contextInfo:(void*)contextInfo {
mFileCtrlDelegator = theDelegator; // typed as id at the
top
[NSApp beginSheet:[self window]
modalForWindow:parentWindow
modalDelegate:self
didEndSelector:@selector(sheetDidEnd:returnCode:contextInfo:)
contextInfo:contextInfo];
[NSApp runModalForWindow:[self window]];
}
Within SheetController's sheetDidEnd, I call:
[mFileCtrlDelegator doSheetSelection:returnCode
contextInfo:contextInfo];
Since mFileCtrlDelegator is anonymous-ly typed as an id pointer
within my showSheet, I include the informal protocol:
@interface NSObject (SheetController)
- (void) doSheetSelection:(int)returnCode contextInfo:
(void*)contextinfo;
@end
_______________________________________________
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