views:

104

answers:

1

I'm wondering how one would implement an outline view like the one Xcode 3 is using for the build configuration:

alt text

When using an NSOutlineView/NSTableView with bindings and an NSTreeController/NSArrayController, the view's columns get bindings assigned to, not the individual cells, for obvious reasons. If every row in a column uses the same cell, then it's a piece of cake. However if every row (potentially) uses its own cell type (and with that potentially its very own collection of bindings), then things get funky.

Looking at the screenshot one can clearly see that the textfield cell needs just a single binding for "value". While the popup button cell needs at least one for "content", one for "contentValues" and last but not least one binding for "selectedIndex / selectedObject / selectedValue". And the checkbox cell needs a binding for "value" and (probably) one for "title".

How would one accomplish this with as clean (and little) code as possible?
(Or as one might ask: How would Apple have done it?)

Here's what I've tried myself so far:
I provide the appropriate (copied) cells via [outlineView:dataCellForTableColumn:item:] and bind them to the individual data models (from [item representedObject]). I know the exact amount of data (< 500 rows) being displayed in the outline view, so having one cell per row shouldn't be too much of a memory issue, no? I got the data to get displayed properly via bindings (yay!) however I'm unable to change any of their values. O_o Apparently the value change simply never gets thru to the data model. Is there more to it than a simple [checkboxCell bind:@"value" toObject:rowModel withKeyPath:@"value" options:nil]? (as this seems sufficient for getting values, but not for setting them accordingly.)

I couldn't find any information on this topic. Lots of info and hints for using custom cells per column, but none for using them on a "per row" basis. :(
This would make some great stuff for a Cocoa tutorial, wouldn't it? ;)

+1  A: 

The data cell of a column isn't copied. The cell is configured for the proper value for the column in each row and drawn in its proper place. A good place to hook in is at the NSTableColumn method -dataCellForRow:. In a custom subclass, you could override this method and pass either its -dataCell for normal operation or some alternate cell type.

I had an occasion to have a checkbox column representing "include" in an outline view that only appeared for children (non-root items). The root items couldn't be excluded, only their children, so it made sense only to show the checkbox for non-root items.

I created a custom NSTableColumn subclass that took a delegate (my data source controller) and checked to see if it responded to the selector -deadCellColumn:shouldShowDeadCellForRow:. If it did, I called that method (which was implemented on my data source controller) to ask it if I should show a "dead cell" (a basic NSCell subclass that draws nothing) and swapped it according to the answer. If the delegate didn't respond to the selector, the table column returns its normal -dataCell.

The custom cell (which I called "DeadCell") was needed here because I wanted to ensure nothing got drawn and nothing was editable. I'm not sure it was strictly necessary but I did it anyway. This isn't much use in your case, but I wanted to state it anyway for completeness.

Your situation is a bit more complicated, especially because Bindings are involved (and different data cell types can have different bindings for their value -- popups can be especially challenging). In my case, I eschewed bindings for the tried-and-true data source mechanism. It simplified things greatly. :-) For your case, it's easy enough to swap cell types around using data source methods.

Joshua Nozzi
Oh my… I guess I'll _'just'_ have to unify my data input then (using ComboBoxCells for easy access to template values) and use NSFormatters for ensuring proper input for each item's value type. Not pretty, but the feature that requires such table view simply isn't big/important enough to invest such huge backend code and likely hackery into. Major bummer though that such stuff is such a mess to work with.
Regexident
There's no hackery involved at all. It's all valid use of the control/cell mechanism. Also, Cocoa Bindings are more toward the 'rapid application development' side of things, which only eliminates code for the more generalized cases. If you want to do special things, you have to use code. In many situations, you can mix the two (bindings and data source). In this situation, if your cell types all share the same bindings, you only need your custom column and everything else should "just work."
Joshua Nozzi
Yeah, but they do **not** share the same bindings :(And the feature is gonna be a nerdy one anyway, with a very limited potential userbase, so simply not worth such an excessive effort while delaying product release. :( "great developers ship", right? ;)But thanks for the solution. I'm sure I'll have some use for it not too far away.
Regexident
A reasonable choice. I've learned that, whenever possible, it's best to think up front whether I'll want to do things that go beyond Cocoa Bindings' comfort zone (I frequently do) and commit to coding my controllers using the "Tried and True" data source methods and notifications. They're not as "rapid" as RAD technologies (obviously) but they make inserting a quick little bend into the logic far easier in the long run. I use bindings only for simple things (like NSUserDefaultsController + preference panel) these days.
Joshua Nozzi