Re: 2 TableViews - 1 Controller - Best Practice?
Re: 2 TableViews - 1 Controller - Best Practice?
- Subject: Re: 2 TableViews - 1 Controller - Best Practice?
- From: Jack Nutting <email@hidden>
- Date: Tue, 13 Sep 2005 10:29:50 +0200
On 9/13/05, Steve Cronin <email@hidden> wrote:
>
> -(id)tableView:(NSTableView *)aTableView objectValueForTableColumn:
> (NSTableColumn *)aTableColumn row:(int)rowIndex
> {
> if ([[aTableView autosaveName] isEqualToString:@"A"]) {
> NSParameterAssert(rowIndex >= 0 && rowIndex < [aArray count]);
> return [[aArray objectAtIndex:rowIndex] objectForKey:
> [aTableColumn identifier]];
> }
> if ([[aTableView autosaveName] isEqualToString:@"B"]) {
> NSParameterAssert(rowIndex >= 0 && rowIndex < [bArray count]);
> return [[bArray objectAtIndex:rowIndex] objectForKey:
> [aTableColumn identifier]];
> } else {
> NSLog(@"Unexpected tableView: %@,[aTableView autosaveName]);
> return [NSString stringWithString:@"Unexpected tableView"];
> }
> }
>
> I know that efficiency is really paramount here (isn't always?) so:
>
> 1) is the NSParameterAssert useful or necessary? Does Cocoa itself
> make it unnecessary?
Assuming that you've implemented numberOfRowsInTableView: using a similar
mechanism, returning [aArray count] or [bArray count] as appropriate, you
shouldn't need that assert, since whenever NSTableView is updating its
display, it always asks for the number of rows first.
2) Is there a way to generize the code by getting the datasource
> array from aTableView so I wouldn't have to hard code those values?
Not really. The point of the NSTableView datasource concept is that YOU
manage the array. However, you could probably benefit by using Cocoa
Bindings instead of implementing the datasource yourself.
3) Is the autosaveName a reasonable way to distinguish them?
A much more common pattern in my experience is to have IB outlets to the
tableviews in your controller/datasource, and compare against those, like
this:
-(id)tableView:(NSTableView *)aTableView
objectValueForTableColumn:(NSTableColumn *)aTableColumn row:(int)rowIndex
{
if (aTableView==tableA) {
return [[aArray objectAtIndex:rowIndex] objectForKey:[aTableColumn
identifier]];
}
else if (aTableView==tableB) {
return [[bArray objectAtIndex:rowIndex] objectForKey:[aTableColumn
identifier]];
}
}
I also took out that final else clause, since it will surely never be
executed.
Alternatively, you could continue to use the autosaveName, and put your
aArray and bArray inside a dictionary keyed with the same strings you have
in the autosaveName for the tables, then the method becomes even shorter:
-(id)tableView:(NSTableView *)aTableView
objectValueForTableColumn:(NSTableColumn *)aTableColumn row:(int)rowIndex
{
return [[[arrayDict objectForKey:[aTableView autosaveName]]
objectAtIndex:rowIndex] objectForKey:[aTableColumn identifier]];
}
4) Am I way out in the weeds and there is just a much better way to
> do this?
>
It's entirely possible to get the datasource methods working nicely without
a whole lot of effort, but it's really the "old way" of doing things now;
I'd really recommend you look into Cocoa Bindings instead. You can do all
this, and more, without any code at all using Cocoa Bindings. And then, with
a little bit of code, you can do entirely new classes of things that would
require lots more code if you did it the old way.
--
// jack
// http://www.nuthole.com
_______________________________________________
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