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: Luke Evans <email@hidden>
- Date: Sun, 20 Mar 2011 00:48:56 -0700
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 <email@hidden
> 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 (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