Re: Visual feedback of invalid cell data from Core Data - how to?
Re: Visual feedback of invalid cell data from Core Data - how to?
- Subject: Re: Visual feedback of invalid cell data from Core Data - how to?
- From: Quincey Morris <email@hidden>
- Date: Sun, 20 Mar 2011 01:34:15 -0700
On Mar 20, 2011, at 00:48, Luke Evans wrote:
> However, my original query was motivated by general curiosity as to whether the Core Data constraints could readily be surfaced to bound UI in some way, without the whole error mechanism that goes with the validate<key> protocol, and indeed the way -save: works. Core Data constraints are clearly a great way to express some kinds of static validation that are deemed important enough to protect from persisting invalid documents/state. It seemed like there should be a nice way to have those same constraints manifest 'early' as validation state you could surface in the UI, before being hit with errors that are much more difficult to trace back to the original source of validation issues.
It's clearer now what kind of solution you were looking for, so I'll take another stab at answering. This is meant to be more encouraging than the last answer, but not too encouraging ...
I think Core Data actually does take care of the manifesting-early part of your goal. Take a look at 'validateForUpdate:' and friends, and follow the handful of documentation links that you'll find starting there. (I have to admit, though, that I have no idea whether 'validateForUpdate:' is something Core Data calls every time a property changes, or whether you're supposed to call it from somewhere else to trigger a validation pass. I've never actually tried to use it, and the documentation seems to omit this crucial piece of information.) However it's triggered, it's a fairly neat validation mechanism that does not in itself require you to write any per-property code if you're using entity-defined constraints.
The trouble is, in an ideal world, the UI for (especially) a Core Data application is driven by bindings -- because Core Data just comes out so much more neatly that way -- but bindings need properties and there simply aren't any properties handed to you here, AFAIK.
You could certainly have your UI query the model state, and you could certainly automate that (in terms of enumerating properties). Together with the above model validation process, you'd have a very neat, almost codeless system.
The problem with this approach is that there's no KVO compliance in the validation state, hence no KVO notifications. That means, in turn, (assuming you don't want to create all the validation properties as mentioned before) polling the validation state. That wouldn't be horrible -- 'performSelector: ... afterDelay:' would probably be your friend here -- unless your data set is quite big.
I suspect that this is one of those things that turns out to be surprisingly easy, but it takes a very firm grasp of a number of basic Cocoa technologies.
_______________________________________________
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