Re: NsTableView and the form view.
Re: NsTableView and the form view.
- Subject: Re: NsTableView and the form view.
- From: Sean Murphy <email@hidden>
- Date: Mon, 18 Dec 2006 13:30:35 -0500
Thanks for clarifying your situation Sandro. I still believe
utilizing bindings is (by far) the most advantageous approach, but
here are some more suggestions based upon your existing code…
i'm using this delegate to detect selection changes.
- (BOOL)tableView:(NSTableView *)aTableView shouldSelectRow:(int)
rowIndex;
this delegate is declared inside the dataset.
This delegate method is geared more towards disallowing the selection
of a particular row (which explains the BOOL return type). The
tableViewSelectionDidChange: and TableViewSelectionIsChanging:
methods are more appropriate for monitoring the selection and
responding to a change. These instead supply only one parameter: a
NSNotification object. Your implementation of these methods can
obtain the corresponding NSTableView (whose selection changed) by
calling [aNotification object].
since this is a different Object that has no reference to the
window controller, i'm having a hard time
assigning the title of the textfields.
i did try and pass a week reference to the controller, but then i
would have to implement setter methods to all the 25 fields of the
window, it that how it's supposed to work ?
Composing the NSTableDataSource of objects supporting key-value
coding and indexed accessor methods will eliminate such a need.
This, for example, means your model object could be an NSArray
containing multiple NSDictionary instances.
Really simple master-detail interface functionality:
- (void)tableViewSelectionDidChange:(NSNotification *)aNotification
{
NSTableView *tableView = [aNotification object];
if ([tableView numberOfSelectedRows] > 1)
// Display placeholders since multiple rows are selected
return;
// Obtain some detail about the selected object
id selectedObject = [[self dataModel] objectAtIndex:[tableView
selectedRow]];
NSString *name = [selectedObject valueForKey:@"Name"];
}
Note: dataModel could be an NSArray populated with instances of
NSDictionary, but also any other set of custom objects that is key-
value compliant. See: <http://developer.apple.com/documentation/
Cocoa/Conceptual/KeyValueCoding/Concepts/AccessorConventions.html#//
apple_ref/doc/uid/20002174-178830-BAJEDEFB>
Referencing objects based upon an index works even when sorting is
permitted. NSTableViews do not manage data, meaning the model object
itself would have to change its sort order. If the table was somehow
sorted independently of the data, referencing objects by a row index
would obviously break, but this isn't the case. An example of how
data is sorted:
- (void)tableView:(NSTableView *)aTableView sortDescriptorsDidChange:
(NSArray *)oldDescriptors
{
// Note that the model object itself is sorted.
[model sortUsingDescriptors:[aTableView sortDescriptors]];
[aTableView reloadData];
}
So, to summarize, composing the data source of key-value compliant
objects is extremely beneficial. By the time you're finished coding
the entire data source you will see why Cocoa Bindings exist. In
most cases it can make all of that glue-code go away. Bindings
really shows its ability to eliminate hand-written code when dealing
with multiple selections, sorting, filtering, and other advanced
table-related features.
This technical stuff, such as KVC, might just seem like yet another
specific technique to learn but it's fundamental to the way Cocoa
works. Even though it might seem like a mess of code now, you'll
eventually reach a point where everything throughout the frameworks
becomes coherent and you become extremely productive. Objective-C,
the Cocoa Frameworks, and techniques such as KVC are the reason so
many awesome (and well-polished) applications are being released
every day which are authored by single developers or very small teams.
I hope this helps, and good luck. (Also: I typed the above methods
in Mail, and kind of quickly, but they should work!) Feel free to
ask any other questions you might have.
-Sean_______________________________________________
Cocoa-dev mailing list (email@hidden)
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