Hmm. I realize that this seems unconventional; that is why I posed the question in the first place.
Perhaps you know something about NSPredicateEditor that I don't, but I think it does not use its delegate in the way you envision. To quote from the docs: -- Unlike NSRuleEditor, NSPredicateEditor does not depend on its delegate to populate its rows (and does not call the populating delegate methods). Instead, its rows are populated from its objectValue property (an instance ofNSPredicate). NSPredicateEditor relies on instances NSPredicateEditorRowTemplate, which are responsible for mapping back and forth between the displayed view values and various predicates. -- In my design, the predicate *is* modelled as an attribute of the SmartGroup entity/class. I have a view controller which instantiates a number of NSPredicateEditorRowTemplates and connects them to an instance of a subclass of NSPredicateEditor. It is this predicate editor which allows the user to modify the predicate. The view controller does not have the ability to interject itself into the predicate creation. This is handled completely within NSpredicateEditor with the help of its NSPredicateEditorRowTemplates. 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? Martin On 2010-07-30, at 5:51 PM, Kyle Sluder wrote: > On Fri, Jul 30, 2010 at 2:11 PM, Martin Stanley > <[email protected]> wrote: >> 2- the invalid predicate breaks the NSPredicateEditor. My >> NSPredicateEditorRowTemplate subclass populates its popup button dynamically >> based on the current contents of an NSArrayController bound to the entity in >> question (e.g., Project). When it tries to match the popup to this predicate >> it complains because there is no longer an entry matching the deleted >> object's name. >> >> However, following your last suggestion, I think the following should work: >> - when a SmartGroup is created, register an observer on its predicate >> attribute. >> - then whenever the predicate is changed: >> - parse the predicate to find all of the objects mentioned (by name), >> and >> - create a bi-directional reference between each object and this >> SmartGroup object >> - then when attempting to delete the object (e.g. a Project) inform the user >> and, if given the go-ahead, clean up all predicates which reference the >> object before asking Core Data to delete the object. > > I think you're going about this backwards. Your predicate should > already be modeled in the document (by a SmartGroup entity or a > collection of related entities) and the predicate editor's delegate > should be the controller responsible for converting between the > predicate editor's representation and your model representation. This > would be evidence of a good MVC design. > > --Kyle Sluder _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
