Re: NSTableView app design
Re: NSTableView app design
- Subject: Re: NSTableView app design
- From: Ondra Cada <email@hidden>
- Date: Thu, 27 Apr 2006 19:19:27 +0200
Scott,
On 27.4.2006, at 19:02, Scott Frankel wrote:
In both Hillegas' chapter on Helper Objects and Apple's online docs
on using NSTableViews, methods are used to explicitly return the
number of rows in a table and the value of an object in a specific
column (as well as setting the value). In the following chapter on
Bindings, none of these methods is called. An NSArrayController
appears to handle those tasks. Do I have this correct? Does using
the view's bindings obviate the need to call
numberOfRowsInTableView:, &c.?
Yup. Generally, with some GUI objects you can choose between the old,
data-source-based approach to púrovide the contents, and the newer,
bindings-based one. The old one is almost always considerably less
convenient, but sometimes tends to be somewhat more flexible.
Note that though for content providing the approaches are self-
evidently mulutally exclusive, you can mix other features--for
example, you can use data source methods designed for drag&drop
support, although you are using bindings for providing the content.
Roughly speaking, if the binding is bound, the data source data
providing methods are never called, but other ones still may.
There is, incidentally, a slight catch (I would even call it a bug,
but not an important one): the GUI objects, given a data source
object, tend to check whether it contains the data content providing
methods *even if they would never call them* since bindings are used.
The work-around, of course, is to implement these methods as simplest
plain ones, like this for an NSBrowser delegate:
// these methods are needed since we are a browser delegate; they are
dummy though, for the browser is controlled through bindings
-(void)browser:(NSBrowser*)sender willDisplayCell:(id)cell atRow:(int)
row column:(int)column {}
-(int)browser:(NSBrowser*)sender numberOfRowsInColumn:(int)column
{return 0;}
Also, if I understand correctly, a tableView object's data source
is considered part of the app's controller, in M-V-C terms.
Definitely.
Using bindings and key-value coding style accessors, the
functionality that would've been handled by the controller is now
accessed directly in/from the model. Is this correct?
Partially. Depending on the concrete app, a slight or considerable :)
part of this functionality is handled controller-level, very often in
categories which extend model objects' functionality in a way the
specific controller (and the appropriate view(s) driven by it) needs.
Although it perhaps could be argued whether such extensions belong to
the controller or model level, myself, I strongly feel the former is
the better interpretation.
---
Ondra Čada
OCSoftware: email@hidden http://www.ocs.cz
private email@hidden http://www.ocs.cz/oc
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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