On Mon, Jul 5, 2010 at 7:36 PM, Graham Cox <graham....@bigpond.com> wrote: > I was hoping to avoid it because if I do that I have to duplicate the work > that NSTableView does to maintain its list of sort descriptors. Since > NSTableView already manages this list, it's easy to use.
I would argue that's less of a concern than inverting the responsibilities of your controller and view layers. If "the sort descriptors in use" is a concept that exists outside of the table view, it really doesn't make sense to make the table view responsible for maintaining it; that's the role of what the documentation would term a "coordinating controller." There are some places where views can be used on their own, maintaining their entire state, or they can be used in conjunction with a delegate or datasource that provides the state on demand. Yes, that means the delegate or datasource has to reimplement some amount of code the view already implements, but it's in the service of a better design for the application developer and a more versatile view class in the framework. In fact, this situation comes up when adding bindings support to a view. You'll wind up reimplementing a little bit of code the existing non-bindings codepath will already have implemented (or will pass off to its datasource), but you wind up with a view that can be bound or used traditionally. > I'd still like to know how a programmatic change to sort descriptors in a > table view ought to be accomplished. It seems that the "highlighted" column > really has logically nothing to do with the table's sort descriptors, even > though when you interact with a table that's exactly what is used to indicate > the sorted column. Weird. I believe NSTableView is expecting you to take responsibility for presenting it the sort descriptors in the right order. If you bind its sortDescriptors binding to your controller, I would expect that reordering and clicking on columns pushes the new sort descriptors down the binding. So that's some built-in functionality that you don't have to give up. --Kyle Sluder _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
