Validating against multiple updated Coredata objects
Validating against multiple updated Coredata objects
- Subject: Validating against multiple updated Coredata objects
- From: Jim Thomason <email@hidden>
- Date: Wed, 15 Oct 2014 13:04:13 -0500
Hi,
In my user interface, I can have the user edit a field on an object, and
behind the scenes this will trigger a cascade of other changes to other
objects. As a result, I don't just need to validate the value the user
typed in, I also need to validate all of the other changes that that single
edit will make to all of the related objects.
And I cannot come up with a good way to do it.
Let's say I have an Employee object (with a "name" attribute, a title, a
salary, and a related department), and a Department object (also with a
name, and a list of related employees).
In the interface, I add in a new user, "Jenkins", say he's a "Developer",
who makes $100k, and add him into the "IT" department. This passes all the
constraints on the Employee object (all fields are filled in), so it checks
out there.
But the Department object can have any number of ludicrous other
constraints involved. Maybe IT only wants to hire a single person named
Jenkins and it fails. Maybe IT has too many developers already and it
fails. Maybe by adding a new employee, the Department object automatically
totals up all salaries and sees that they're over the budget and fails.
Maybe the Department hands off that salary total (which is not something
the user typed in or even has any knowledge of!) to a parent Company
object, which rejects it because even though the Department is still within
what it was given as a salary constraint, the company as a whole would not
be. And on and on and on.
Is there a clever way to capture and report errors of this type back to the
user?
I considered stuffing all of the cascading salary logic into a
validateSalary:error: method, for example, but then I'd do all the
calculations for the related objects once when I validate, and then do them
again when I actually set the Salary after all the checks succeed. If
these operations are expensive, then I'd rather not do them multiple times.
AFAIK, I'd have no good location to cache the calculated values created
during the validate routine, short of just stuffing them into some global
variable somewhere.
I tried using validateForUpdate: on the individual objects, but that isn't
invoked until the document is saved, which is potentially long after
changes were made. I can manually call it against all updated objects in
the context, I guess, though this is also a potentially wasteful operation.
As a side note, I've never been able to successfully directly call this
method and have an &error object available for me - they're always nulls,
and hence I can't report anything back.
I've also considered using a customValidateSalary method, called at the end
of setSalary, which does validation on known related objects. But that
breaks down if, for example, the Employee only knows to validate the
Department object and never checks to see if the Company object tossed an
error, because it wasn't even aware of it. To catch all modifications to
all objects, I'm basically back to iterating over all updatedObjects again.
Regardless, at the end of it all, after all the validations against all
objects are performed, if any failed then I could undo the last action to
restore to prior state and alert the user, but I lack the context of
re-highlighting the field the way the standard validateSalary:error:
CoreData methods would work. That's not as user friendly.
I could also rewire all the setters to toss exceptions if an invalid input
falls into them, wrap everything in try/catch blocks, and let them bubble
up only to be captured at the highest level and finally displayed. I still
lose context of which input field the user was typing into, though. Maybe
capture the first responder and re-use that? I dunno.
Does anyone have any suggestions about how to deal with cascading
validation in this manner? It feels like I've got the OO equivalent of a
stack of GOTO blocks to unwind this mess. Any suggestions welcome.
-Jim....
_______________________________________________
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