Re: No validation with a bound NSTableView and custom NSFormatter
Re: No validation with a bound NSTableView and custom NSFormatter
- Subject: Re: No validation with a bound NSTableView and custom NSFormatter
- From: Keary Suska <email@hidden>
- Date: Thu, 03 May 2012 21:04:22 -0600
On May 3, 2012, at 6:11 PM, Ben Kennedy wrote:
> I have re-worked things to take full advantage of bindings now, so as to get the more desirable automated validation handling. However, I've now come up against another challenge.
>
> As I may have alluded in an earlier posting, I need to be able to perform a cascading update on the data set in response to a particular row being edited. Previously, this was trivial to do with a for loop in the delegate's -[tableView:setObjectValue:forTableColumn:row:], but now requires some trickery.
>
> I've found myself overriding -[editColumn:row:withEvent:select:] and -[textShouldEndEditing:] in a NSTableView subclass in order to have a hook into performing an operation post-edit in relation to the modified row. This feels filthy, but I yet haven't seen how better to do it.
>
> I considered that I could register as a KVO observer for each of my data objects (and then use [arrayController.arrangedObjects indexOfObject:object] as the basis for my cascading update), but that requires adding extra -[addObserver:...] code accompanying everywhere I have an [arrayController addObject:], which seems prone to oversight. Is there a better way?
>
> Separate from the above, I also have a new performance problem. The loop in which I do my cascading updates executes inordinately slowly; simply assigning new values for two properties takes about 0.45 seconds when iterating a data set of a mere 135 objects. It used to be instantaneous before bindings came into the picture. I suspect that all of the KVO overhead is to blame (a quick peek in Instruments supports this). Is there something fundamental I'm missing to avoid this bottleneck?
I would say that to have this kind of performance issue generally means that bindings is not being worked with properly, and I would add that doing so is frequently an exceedingly frustrating thing. Following this thread it sounds to me that you would be served best by dumping bindings altogether and using the delegate model. It will give you far more control, will be more obvious and easier to debug, and will be more performant into tens to hundreds of thousands of rows. I know, because I have been in a similar place, although I was experiencing slowdowns when getting into thousands of objects, rather than just 135.
Don't get me wrong, I think bindings are great, and I use them extensively in almost everything I do. But it seems to me they are really built for straightforward usage and if you need to stretch them they tend to break. Not to mention that they are completely opaque and are a bear to debug.
HTH,
Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden