Re: NSTableView & different columns
Re: NSTableView & different columns
- Subject: Re: NSTableView & different columns
- From: Dave Hersey <email@hidden>
- Date: Sun, 03 Jul 2005 00:40:04 -0400
On 7/2/05 11:33 PM, "mmalcolm crawford" <email@hidden> wrote:
> On Jul 2, 2005, at 6:19 PM, Dave Hersey wrote:
>
>> In your PersonObject from above, you'd now create a checkbox object
>> at init
>> time.
> [...]
>> @interface PersonObject : NSObject
>> {
>> NSButtonCell *m_checkbox;
>>
> Don't do this!
>
> See <http://developer.apple.com/documentation/Cocoa/Conceptual/
> AppArchitecture/Concepts/MVC.html>, <http://developer.apple.com/
> documentation/Cocoa/Conceptual/CocoaDesignPatterns/index.html> etc.
>
> There is almost no reason why a model object should keep a view
> object like a control cell as one of its variables. All that's
> needed is to:
>
> 1. Set the cell for the column in the table view.
> 2. In the ... objectValueForTableColumn ... method, return a value
> that's appropriate for the cell (in this case, an NSNumber).
Well, OK, but that's not enough. That's fine if you only need to return a
value, but if your table contains columns of checkboxes or other controls
that can be enabled, disabled and have other attributes that are uniquely
set in each row of a table based on the data that's stored for each object
in the table, something needs to manage it. In that case, the check box is
really a representation of the data in the row's data object, so it seems
like that object should handle it's creation/setup/destruction.
This thread contains a pretty simple example, and if all you need is the
value of the control, I agree. A more complex example would be software that
shows a table with information about each volume that's mounted, and based
on the free space, format, and other attributes of the volume which may
change as volumes are mounted and unmounted, needs to enable/disable
checkboxes, change button labels in the table, change a status image that's
displayed in the table and so on.
You could do all of that in the data source by asking a row object whether
the checkbox should be enabled or disabled, and then applying that change,
asking what the name for a button should be and then setting it, and so on.
Or subclassing NSButtonCell, using that for the table cells, and having that
do the same thing. This just seems more sensible, and its certainly more
efficient, if it's handled by a data object that knows all this and can keep
the controls and status image in sync when any of its internal data changes.
I don't think the object should need to make all of these details public
solely for the sake of MVC. I mean, all we're talking about is setting the
enabled status of a control, setting it's value, and possibly setting its
label. Those are each one line of code unless you rewrite all this to be
less efficient but, I suppose, more MVC.
I had to do something similar to this scenario about the volumes, so if
anyone has a better approach to managing controls in a table, I'm
interested, really.
- Dave
_______________________________________________
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