If the table view's data is related to the document, you should keep this in the document. Putting it in a category when the class is fully under your control seems a bit odd, but you may have a reason for that. You should look at your reservations, though. You're wanting to hook up a "data source" and you're feeling it's too much "view-ish" code for your "data model." Your "view-ish" code may be saying your design needs changing. Consider transformers or formatters if appropriate. Also, view-based tables and collection views open things up to more richer representations that may not require your "view-ish" code.
Your separate, standalone object may be a good solution, too, but think of the has-a, is-a, or uses relationship between your document class and it, and that might help you know who owns your data. -- Gary L. Wade http://www.garywade.com/ On 9/5/2012 5:39 AM, "Jerry Krinock" <je...@ieee.org> wrote: >What is the best the data source for a table view in a document window? >The >candidates are? > >(1) Category of the document. This is the way it is done >in the WithoutBindings ("With and Without Bindings") Apple sample code. >But >it seems like too much "view-ish" code in the data model, particularly >when >my document class is also used in a GUI-less command-line tool, which has >no >need for this code. > >(2) Separate, standalone object. Fancy housekeeping >is needed to avoid retain cycles, and crashes in corner cases as the >document window is closing. > >(3) Category of the window controller. >Probably not a bad choice, except that my window controller for this >multi-tabbed window is already huge. > >(4) Category of the table view >itself, assuming that it is subclassed. Seems like a logical division. >No >worrying about whether table view or its data source gets deallocced >first. >Access the document via [[[self window] windowController] document]. > >* * >* > >I've used (2) but think I'm going to switch to (4). Any important >considerations I've >overlooked? > >Thanks, > >Jerry _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
