Check out my latest product, BuildFactory
Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/globalfunctions.php on line 779
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/BLOG.php on line 170
Core Data, NSTreeController & NSOutlineView (Part One)
Warning: Parameter 1 to NP_Geshi::event_PreItem() expected to be a reference, value given in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/MANAGER.php on line 331
Core Data is one of the more powerful APIs Apple has to offer, when tied to Cocoa Bindings, it becomes much more powerful, and available to amateurs and some pros alike.
Sounds great right? There's a catch (there's always a catch, you should know that by now). Cocoa Bindings, while powerful, are one of the more difficult mechanisms to work within Cocoa-land. The interface you use to interact with them is about as counter-intuitive as if Copy's keyboard shortcut was Apple+Alt+Shift+F5+C.
Another unfortunate catch, is that, the Apple Documentation Team seems to have forgotten, or never heard of Cocoa Bindings, so past a few tutorials here and there, we're pretty much on our own.Binding an NSTableView is easy, but what about avoiding writing an NSOutlineView data source? Cocoa Bindings can do that to! :)
First things first, we need a good Core Data Application Project (a good fresh start never hurt anybody). Inside XCode, just go to File>New Project, and then select the "Core Data Application", name your project, and you're on your way.
From here, we can go on to create our Core Data - Data Model...
Cocoa Bindings, as well as Core Data, tend to be quite picky about naming, so choose wisely; here's my
. Honestly, it's a bit simple, but not obvious right away. Firstly, "entityTitle" is a simple, non-optional, String attribute. Meanwhile, TopLevelEntity's "children" relationship is a To-many (i.e. can point to multiple entity objects) inverse relationship with SecondLevelEntity (the inverse relationship being between TopLevelEntity.children <-->> SecondLevelEntity.parent )Logically, this means that for each data object of type TopLevelEntity, it can relate to an infinite (more or less) number of SecondLevelEntitys via it's "children" relationship. Meanwhile, each data object of type SecondLevelEntity can have only one "parent" entity via it's "parent" relationship (pointing to a TopLevelEntity), and zero "children" (since that is a dead relationship, it's merely there to return nil)
SecondLevelEntity's "children" relationship is optional, and "transient," meaning it is not something that will stick around in the Core Data store.
Now we can set up our interface, and given that this is very simple, we'll set up two window's to add data to the data store (make sure you check "VIsible At Launch Time" for both windows!), as well as to display our nice NSOutlineView (which will be bound to an NSTreeController)
Doing this is remarkably easy, using some features of Core Data. Inside Interface Builder, create a few windows, preferably one for each entity (in addition to the main window) Then click into your XCode Core Data Object Model Window, and Alt+Drag your entity into one of your windows, Interface Builder will then prompt you if you want to create a one, or many interface for the dragged entity, choose "Many Objects", and repeat for the other entity. After you have done this, you should have two nice sets of interfaces, in your last window, the original main window, drop an NSOutlineView control into it. More or less, your finished product should
Now that these are bound correclty, since Interface Builder does this all automagically for us, we can create our NSTreeController, which you can drag from the "Controllers" palette in Interface Builder.
Open up inspector while the NSTreeController is selected, and set it's attributes as such:
You will then have to set that NSTreeController's managedObjectContext via Cocoa Bindings to your pre-generated App_Delegate class (think of the managedObjectContext as the link between your data, and your interface).
Then comes the second to last step, which is to tie your NSOutlineView via Cocoa Bindings to that NSTreeController, which is through the simple addition of the value binding. Double click in the NSOutlineView, and select the column header for the left-most column, and go to the Bindings in the Inspector:
Really, that's about it for now, compile, and run your application, and you shoudl be all set!
Exercises for the reader:
1. Three levels? Five? Eight? Thirteen?!?
2. Add more custom controls that bind to your controllers inside Interface Builder
Download source
Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/globalfunctions.php on line 779
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/ITEM.php on line 61
Replies
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
Thanks a lot for this ... can't wait for part 2 to come out. For Core Data in combination with NSOutlineView there is hardly anything to find on the web.
Now I just need to figure out how to import legacy data into the outline view.
Now I just need to figure out how to import legacy data into the outline view.
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
An Excellent Tutorial!
Looking forward for more on NSOutlineView in Combination with NSTreeController
Looking forward for more on NSOutlineView in Combination with NSTreeController
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
Thanks for the tutorial. But I can't figure out how to do more than two levels. I got about 5 or 6 entities. but I'm stuck on these first two.
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
(Since comment words cannot apparently be greater than 90 characters, URLs are relative to http://developer.apple.com/ and may be broken by additional spaces.)
It's not clear in what sense the Bindings UI in Interface Builder is *counter*-intuitive. There is certainly scope for improvements, but form follows function -- the format follows exactly what is required to set up any binding. You need to specify what to object an attribute is bound, using what keypath and what options. These derive naturally from Bindings basics as described here: documentation/Cocoa/Conceptual/CocoaBindings/Concepts/HowDoBindingsWork.html #//apple_ref/doc/uid/20002373-194182
This tutorial provides a poor example for the Core Data model. You should typically not create a schema that models a relationship in only one direction. This is documented here: documentation/Cocoa/Conceptual/CoreData/Articles/cdRelationships.html #//apple_ref/doc/uid/TP40001857-DontLinkElementID_88
This is not made clear, nor is it made clear what is the purpose of making the reciprocal relationship transient.
If you want to denote that a node does not have children, you are strongly encouraged to provide a 'leaf' key path (see documentation/Cocoa/Reference/ApplicationKit/Classes/NSTreeController_Class).
You certainly do not *need* a Core Data Application to make use of NSTreeController. Moreover, if you're just getting started with bindings, you are strongly discouraged from trying to learn Core Data at the same time (see documentation/Cocoa/Conceptual/CoreData/Articles/cdBeforeYouStart.html).
It's not made clear in what sense Cocoa Bindings is "picky" about naming, at least from the perspective of configuring bindings in IB. Bindings will only work correctly if you bind to correctly-named KVO-compliant values (see the Bindings and KVO documentation). That's no more or less "picky" than the compiler requiring that you spell variable names correctly.
Core Data does impose some constraints on property names. These though are not bindings-related, and are documented here: documentation/ Cocoa/Reference/CoreDataFramework/Classes/ NSPropertyDescription_Class/Reference/Reference.html
Apple provides several tutorials, guides, and reference collections that describe Bindings and Core Data, including
documentation/Cocoa/Conceptual/CocoaBindings/index.html
cocoa/cocoabindings.html
documentation/Cocoa/Reference/CocoaBindingsRef/index.html
documentation/Cocoa/Conceptual/CoreData/index.html
documentation/Cocoa/Conceptual/NSPersistentDocumentTutorial/index.html
cocoa/coredatatutorial/index.html
It's not clear in what sense the Bindings UI in Interface Builder is *counter*-intuitive. There is certainly scope for improvements, but form follows function -- the format follows exactly what is required to set up any binding. You need to specify what to object an attribute is bound, using what keypath and what options. These derive naturally from Bindings basics as described here: documentation/Cocoa/Conceptual/CocoaBindings/Concepts/HowDoBindingsWork.html #//apple_ref/doc/uid/20002373-194182
This tutorial provides a poor example for the Core Data model. You should typically not create a schema that models a relationship in only one direction. This is documented here: documentation/Cocoa/Conceptual/CoreData/Articles/cdRelationships.html #//apple_ref/doc/uid/TP40001857-DontLinkElementID_88
This is not made clear, nor is it made clear what is the purpose of making the reciprocal relationship transient.
If you want to denote that a node does not have children, you are strongly encouraged to provide a 'leaf' key path (see documentation/Cocoa/Reference/ApplicationKit/Classes/NSTreeController_Class).
You certainly do not *need* a Core Data Application to make use of NSTreeController. Moreover, if you're just getting started with bindings, you are strongly discouraged from trying to learn Core Data at the same time (see documentation/Cocoa/Conceptual/CoreData/Articles/cdBeforeYouStart.html).
It's not made clear in what sense Cocoa Bindings is "picky" about naming, at least from the perspective of configuring bindings in IB. Bindings will only work correctly if you bind to correctly-named KVO-compliant values (see the Bindings and KVO documentation). That's no more or less "picky" than the compiler requiring that you spell variable names correctly.
Core Data does impose some constraints on property names. These though are not bindings-related, and are documented here: documentation/ Cocoa/Reference/CoreDataFramework/Classes/ NSPropertyDescription_Class/Reference/Reference.html
Apple provides several tutorials, guides, and reference collections that describe Bindings and Core Data, including
documentation/Cocoa/Conceptual/CocoaBindings/index.html
cocoa/cocoabindings.html
documentation/Cocoa/Reference/CocoaBindingsRef/index.html
documentation/Cocoa/Conceptual/CoreData/index.html
documentation/Cocoa/Conceptual/NSPersistentDocumentTutorial/index.html
cocoa/coredatatutorial/index.html
Write reply
This item is closed, it's not possible to add new comments to it or to vote on it
Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 391
05:52AM,
Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/globalfunctions.php on line 1112
Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/globalfunctions.php on line 1132
16/03/06