Re: CoreData: filtering controller content
Re: CoreData: filtering controller content
- Subject: Re: CoreData: filtering controller content
- From: email@hidden
- Date: Thu, 9 Jun 2005 15:04:27 -0700 (PDT)
- Importance: Normal
Scott, I just came across your response, don't know how I missed it the
first time.
>> I actually can't even figure out how to filter out the object I'm
>> editing from the list of types. The object is selected in an
>> ArrayController called Types. I want a second ArrayController
>> called ParentTypes to contain all the valid choices for a parent.
>
>It's pretty hard to follow this without seeing how you have things
>laid out, but I *think* you could do this by implementing a custom
>method like:
Basically, it's invalid for an object to be it's own parent. How do I get
a list that doesn't include the selected object?
>- (NSSet *) parentTypes
>{
> return [self valueForKeyPath:@"parent.types"];
>}
>
>You could then bind the ParentTypes array controller to the Types
>array controller, with the "selection" controller key and
>"parentTypes" as the model key path.
>
>Does that do what you want?
I'm not sure, but I don't think so. Let me see if I can explain it more
clearly.
Types are like classes (I'd use class but it's reserved in CoreData) and I
have a "type hierarchy" just like OO languages have a class hierarchy.
When editing a type definition I want to user to be able to select the
parent type (super class). I want to give the user a popup list to choose
the parent, but I need to filter out all types that are currently
descendants of the type in order to avoid loops.
I have a method called descendants, and I can use bindings to get a popup
list of all the *invalid* choices, but I can't get a popup list that has
everything but the current objects descendants.
>> However, for some reason I think of this as really extending the
>> behavior of the controller. I'm tempted to subclass
>> NSTreeController and add methods for retrieving objects along the
>> different axes. Good idea or bad idea?
>
>Not sure exactly what you mean. It doesn't sound like it's in the
>spirit of Cocoa/MVC design patterns, though.
Have you ever worked with XSL? I'm trying to get some of the functionality
of XPath because it's real easy to work with trees through "axes". There's
the ancestor axis, the descendant axis, the previous siblings axis, etc...
So let's say I have a NSTreeController and I want an array of all the
descendants of the currently selected object. It's pretty trivial to do
this by creating a second NSTreeController who's content set is bound to
the first controller's selection's children. Something like
contentSet = TreeController1.selection.children
It'd also be trivial to get the descendants from the object itself by
recursing the children. But how would I do set operations that involve
objects not connected to the current selection? And who should be in
charge of these operations to fit in with MVC? If I want all objects that
aren't a descendant, should that be a function of the Controller? The
selected object might not have all the information necessary to figure
that out.
I haven't thought about this problem for a few days, so I hope I'm being
comprehensible right now. Thanks for the help though.
-Justin
Oh, maybe I should diagram some of my data model:
Type:
name
parent <<--> Type
children <-->> Type (inverse of parent)
items <-->> Item (inverse of Item.type)
Item:
name
type <<--> Type
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden