Re: Design patterns
Re: Design patterns
- Subject: Re: Design patterns
- From: Mike Abdullah <email@hidden>
- Date: Sun, 23 Jul 2006 17:52:34 +0100
On 23 Jul 2006, at 12:46PM, Trygve Inda wrote:
I am wondering what the general consensus is on handling sheets. I
currently
have two simple sheets managed by my AppController which require a few
methods:
- (IBAction)showPluginWindow:(id)sender
- (void)pluginTableDoubleClick:(id)sender
- (IBAction)okButtonAction:(id)sender
- (IBAction)cancelButtonAction:(id)sender
- (void)sheetDidEnd:(NSWindow *)sheet returnCode:(int)returnCode
contextInfo:(void *)contextInfo
I have similar methods for a prefs sheet. Should these be put into
separate
objects?
Both sheets act upon data that the main app needs to know about,
although
with the prefs sheet I have a dict in my main app that just has a
series of
keys for the user preferences.
The sheets are stored in my main nib file. Is there any advantage
to moving
them to their own nib and making the separate objects?
I don't know in your particular case (it all depends what the sheet s
doing really), but I generally put my sheets in their own NIB and
make the owner a custom NSWindowController. I then create the window
controller when the sheet is required and use the window controller
to handle any logic specific to the sheet.
If I had a complex window that really needed a window Controller, I
would
use a different nib and make it an object, but for relatively
simple sheets
with a few controls, what do the masses think?
I guess some of this leads to... How many methods in a class is
reasonable
and is there any way (good idea?) to move some of them into a separate
source file. (Can, or is it normal for a class have more then
one .m file?)
I think you're after a "Category" :)
Thanks,
Trygve
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40gmail.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden