[Ghoser777]

I really liked the idea of using NSMutableArray's as my data source for table views via categories until I ran into a little snag. It seems that categories are global in every sense. If I add a category to NSMutableArray in one implementation file, then all instances of NSMutableArray inherit it. I would, of course, like separate implementation files to have their own category added to NSMutableArray, using the same methods, but with different bahvior.

I guess this is just the way Categories work, although I think it really limits their power as a data source tool.

Matt Fahrenbacher

[00101001]

what about subclassing NSMutableArray?

[Ghoser777]

Originally posted by 00101001:
what about subclassing NSMutableArray?

Hmmm... that's a fine idea that I didn't think of doing. It would force me to do a little extra work converting between subclasses and superclasses somewhere in my program logic, but that definitely sounds like the way to go.

Thanks for the obvious idea that I missed,
Matt Fahrenbacher

[tobli]

Don't subclass, there's absolutely no need for that. Also, NSArray is a class cluster, and not really intended for subclassing. What are the differences in behavior that you wish to have. That doesn't sound like it would belong in a category on NS(Mutable)Array. The NSTableDataSource protocol is so simple there's really no room for different behavior.

[Ghoser777]

Originally posted by tobli:
Don't subclass, there's absolutely no need for that. Also, NSArray is a class cluster, and not really intended for subclassing. What are the differences in behavior that you wish to have. That doesn't sound like it would belong in a category on NS(Mutable)Array. The NSTableDataSource protocol is so simple there's really no room for different behavior.

Okay, so don't subclass (I forgot about it being a class cluster).

The only different behavior was going to be the identifier to check for and the values to return (and in turn the type of values that are stored in the NSArray). So if I have two table's that have an NSArray datasource, I'd much rather have two categories that relate to the specific table than one that deals with both. It's no biggie, just cleaner.

Matt Fahrenbacher

[Rickster]

Don't use an NSArray (subclass or category) directly as the data source for your table. (In other words, [tableView setDataSource:myArray] is bad.) This is contrary to the Model-View-Controller design philosophy Cocoa is built around -- sure, you can ignore MVC here or there, but the bigger your project gets and the more Cocoa API you use, the more it'll come back to bite you.

You should already have a controller class (perhaps a window controller) that manages the window containing the table view(s) -- it's quite simple to make it the mediator between Model and View:

Code:
- (void)awakeFromNib;
{
	[thisTable setDataSource:self];
	[thatTable setDataSource:self];
	// can be done in IB, actually
}

- (int)numberOfRowsInTableView:(NSTableView *)tableView;
{
	if (tableView == thisTable)
		return [thisArray count];
	else
		return [thatArray count];
}

- (id)tableView:(NSTableView *)tableView objectValueForTableColumn:(NSTableColumn *)tableColumn row:(int)row;
{
	// assumes a one-column table, just add more if's for more columns. 
	if (tableView == thisTable)
		return [thisArray objectAtIndex:row];
	else
		return [thatArray objectAtIndex:row];
}

// optional
- (void)tableView:(NSTableView *)tableView setObjectValue:(id)object forTableColumn:(NSTableColumn *)tableColumn row:(int)row;
{
	// assumes a one-column table, just add more if's for more columns. 
	if (tableView == thisTable)
		[thisArray replaceObjectAtIndex:row withObject:object];
	else
		[thatArray replaceObjectAtIndex:row withObject:object];
}

If you have a bunch of identically laid out tables (just with different data) and you're looking for a way to avoid writing these methods in every window controller, perhaps you should consider writing a TableController class of some sort: give it an array and a table view, and it'll do the above mediation. (This is left as an exercise to the reader.)

HTH,

[Ghoser777]

Oh I know how to do it that way as well. I just knew that Apple had posted some ways to do table data sources with NSArray categories and I really liked the convenience of just using NSArray's instad of NSObject subclasses.

Oh well, thanks,
Matt Fahrenbacher

[Chuckit]

Well, if you really want to use an NSArray category, you could just put a bunch of control statements in your data source methods--they all include the client tableview as an argument so that one class can handle several different tables.

Naturally, of course, what Rick said still holds up--it's not very good style. But if you want to go the NSArray route, that seems like the way to do it.