On 2010-07-31, at 12:54 AM, Kyle Sluder wrote: > >> However, my subclass of NSPredicateEditor overrides the objectValue method >> (to catch errors such as the one I described earlier). It would be possible >> to parse the predicate and create back-pointers at this point. This is >> called every time the predicate is changed. Would this be a better approach? > > Yes, I would expect that whatever controller is setting and retrieving > the objectValue from the predicate editor would be doing the necessary > communication with the model to keep the view and model in a > consistent state. The best thing to do might be to use this > opportunity to convert from NSPredicate instances (for the predicate > editor's objectValue) to collections of managed objects that model the > predicate. Then Core Data delete rules and validation will take care > of all the consistency, rather than forcing this logic into the > controller or view.
I agree that it would be nice to let Core Data handle as much of the referential integrity, etc. as possible; in fact that was why I posed the question in the first place. The problem is that one cannot "convert from NSPredicate instances (for the predicate editor's objectValue) to collections of managed objects that model the predicate" because this would alter the semantics of a SmartGroup significantly. A SmartGroup is meant to have its conditions (predicates) evaluated at runtime (and continuously, at that). But if the predicate is converted to a set of objects at predicate creation/update time this would be impossible. I have started to experiment with setObjectValue to see if this is where I can keep track of all mentioned entities (objects). At the moment it appears that setObjectValue in my subclass is not being called for every change to the predicate. If this is in fact the case, I will have to resort to using a notification on the predicate as I suggested earlier. I need to do more experimenting to understand what is really going on. Martin _______________________________________________ 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
