Re: Best data source for table view in document window
Re: Best data source for table view in document window
- Subject: Re: Best data source for table view in document window
- From: Chris Hanson <email@hidden>
- Date: Wed, 05 Sep 2012 12:48:32 -0700
On Sep 5, 2012, at 11:53 AM, Seth Willits <email@hidden> wrote:
> In a complex window where there a multiple tabbed views like you have, think of the window controller as doing nothing more than managing the view controllers for each of the tabs, not the actual views in each tab. If your window controller is getting monolithic, it's time for a refactor.
Amen to that: You can really start to encapsulate portions of your view well this way, and the way they interact with your model as well.
> There's a view controller responsible for doing nothing more than managing the table view displaying the query results table, and basically has this interface:
>
> @interface ResultListViewController : NSViewController {
> NSTableView * resultListTableView;
> NSArrayController * resultListArrayController;
> }
>
> @property (readwrite, retain) NSArray * results;
>
> @end
>
> The view controller is the delegate and data source for the table view and manages a bunch of little things related to the table.
To go into a little more detail, I’d write the above like this, using Xcode 4.4 or later:
In CMHResultListViewController.h:
#import “CMHViewController.h”
@interface CMHResultListViewController : CMHViewController
@property (readwrite, copy) NSArray *results;
- (id)init; // designated initializer
@end
In CMHResultListViewController.m:
#import “CMHResultListViewController.h”
// Class extension for UI, it's not part of this class’s API.
@interface CMHResultListViewController () <NSTableViewDelegate, NSTableViewDataSource>
@property (readwrite, assign) IBOutlet NSTableView *resultListTableView;
@property (readwrite, assign) IBOutlet NSArrayController *resultListArrayController;
@end
@implementation CMHResultListViewController {
@private
// …additional ivars that may be needed…
}
// …rest of implementation…
@end
With this, I would:
- Use a “base subclass” of NSViewController for my project, in which I can implement project-wide functionality. (For example, I could make -init the designated initializer for such controllers, and have them derive their nib name from their class name.)
- Separate things needed by Interface Builder (IBOutlet, delegate & data source protocol declarations) from the API of the class as used by the rest of the class.
- Avoid declaring ivars that I don’t need to any more, since they’ll be auto-synthesized for me.
- Avoid declaring ivars in the interface to the class, giving clients of it details that they should actively avoid caring about.
- Make Interface Builder go through accessors (by putting the IBOutlet marker on the property declarations) rather than straight to ivars, allowing a little more flexibility.
Of course, this all assumes using the latest tools and compiler, and no requirement to remain compatible with 32-bit Intel (the old ObjC runtime). If it had to remain compatible, though, about the only thing I’d have to do differently is put ivar declarations in the main @interface in the header file.
-- Chris
_______________________________________________
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