• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: NSBrowser, NSTreeController and Core Data
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSBrowser, NSTreeController and Core Data


  • Subject: Re: NSBrowser, NSTreeController and Core Data
  • From: "Mark ." <email@hidden>
  • Date: Tue, 14 Oct 2008 10:15:31 -0400


On Oct 13, 2008, at 15:44, Quincey Morris wrote:

> Your relationship is from categories to subcategories (and inversely
> from categories to parent categories). So calling the relationship
> "id" makes no sense. IAC, to-many relationship names make more sense
> if they're plural ("categories" instead of "id", and "parentCategory"
> instead of "parentID").

But I'm going to need to know the id of the category the user ultimately selects. And, I'm reading it as one parentID to-many ids.

> If 'childNode' is of a Cocoa class like NSXMLNode, [childNode
> stringValue] is going to return the same value each time, which
> doesn't look like what you want. If you're trying to get to various
> XML nodes or attributes, you're going to have to do it a different
> way. (Or perhaps you've invented a class that returns different
> results each time.) This all suggests that you believe that the
> relationships are implemented by matching of (string) names. They're
> not. Relationships are object references. Core Data is an object
> graph, not a database.

I'm sorry. I should have included the other code. I realize that relationships are object references. I am handling it in a different way. I'm looping through the nodes. Also, what I had as "childNode", is actually "categoryChildNode".

// Get an enumerator that contains all the children of this one category listed in the XML

NSEnumerator *categoryChildEnumerator = [[categoryNode children] objectEnumerator];
NSXMLNode *categoryChildNode = nil;


while (categoryChildNode = [categoryChildEnumerator nextObject]) {

   NSString *categoryChildName = [categoryChildNode name];

   if ([categoryChildName isEqualToString:@"CategoryName"])
   {
       [category setValue:[categoryChildNode stringValue] forKey:@"name"];
   }
   else if ([categoryChildName isEqualToString:@"CategoryID"])
   {
       [category setValue:[childNode stringValue] forKey:@"id"];
   }
   else if ([categoryChildName isEqualToString:@"CategoryParentID"])
   {
       [category setValue:[childNode stringValue] forKey:@"parentID"];
   }


... and so on

}

All this works fine with core data and an NSTextView.

> When you create a category object, it's going to have no subcategories
> yet, so there's nothing to set for that relationship immediately. If
> it has a parent, you need to find the parent object (possibly via the
> name of the parent object, which is another subject), and set that
> object for the parent relationship. (The inverse will get set
> automatically.)

> The to-many relationship is a NSSet, so if you ever need to add or
> remove subcategories from an object directly, you would use NSSet
> accessors. You won't use [setValue:forKey:] for that.

Given the error I received, I guess this is really my main question then. How do I do this? Do I need to create a custom managed object class?

Regards,
Mark.


_______________________________________________

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


  • Prev by Date: Re: replacing carbon menu with cocoa
  • Next by Date: Re: UI elements in custom view mess up drawing
  • Previous by thread: Re: NSBrowser, NSTreeController and Core Data
  • Next by thread: Re: NSSpellChecker (foundation) broken for custom NSSpellServer servers
  • Index(es):
    • Date
    • Thread