Thanks Quincey and Jerry for the responses. I was fishing for whether there was a clever Cocoa/Core Data way to get 'friendly' validation warnings like UI highlighting automatically propagated up to the UI from the existing managed object properties without a lot of extra coding overhead. Cocoa bindings do many things so well that it seemed like such a direct mechanism for this might just be in there somewhere... though I hadn't stumbled on it in various readings of the docs.
So it looks like a doubling up of the properties for the managed object properties I care about validating is the way to go to get the visual feedback (per the "isXXXValid" approach). In my current application, I probably could leave the 'hard' Core Data validation turned off, as I'm really only producing warnings of unprovided values (non-fatal consequences). 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. Anyway, I think I have my answers for how it is with the current Cocoa/Core Data situation. Cheers. -- Luke On Sat, Mar 19, 2011 at 2:55 PM, Quincey Morris <quinceymor...@earthlink.net > wrote: > On Mar 19, 2011, at 13:44, Luke Evans wrote: > > > I definitely want the regular Core Data validation process to propagate > and > > drive this, rather than having to set formatters on all my cell (or > > something) and manually figure out validation by some means. > > I think your want might be internally self-inconsistent, but it depends > what you mean by "regular" Core Data validation. It's not clear if you're > trying to rely on entity value constraints in the Core Data model, or > validate<Key> methods in managed object subclasses, or something else. > > I think you have to ask yourself: > > Can I tolerate having invalid values stored in my data model, even > temporarily? > > If the answer is YES, then I'd suggest you don't handle this as > property-level validation in the usual sense. Instead, create some derived > 'isXXXValid' properties in your managed object subclass, which uses > 'keyPathsForValuesAffectingIsXXXValid' to get KVO compliance. Bind something > in your UI to these properties to decide what background color to use. > > In this case, you'd add code at (say) save time to re-check for validation > errors and put up an alert. I believe this kind of deferred validation is > discussed in the Core Data documentation. > > If the answer is NO, then you're going to have to create intermediate or > shadow properties, say in the window controller, which *are* allowed to be > invalid, and then figure everything out from there, using the above > technique or something different. > > In this case, you'd have to transfer the values into the model at (say) > save time, provided they're valid at that point. > > Note that Core Data doesn't give a damn if you pollute your data model with > invalid attribute values, even violations of entity-declared constraints, > until it gets to a save. At that point it will refuse to save if there are > any errors it can detect, and return an entire array of error objects. > > > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
