On Sat, Feb 7, 2009 at 1:05 AM, <jmun...@his.com> wrote: > Actually, it isn't obvious. If it were, I'd get it. The reason "selection" > didn't work (and I should have seen that earlier) is that it is singular in > nature. If you create a "form," with "fields" on it, you'd use selection as > you are only dealing with one record at a time (in what I'm doing, > "selection" is the same as "currently selected record"). This is simply not > functional for a tableview as the tableview works off of collections of > objects. Setting the SelectedObject binding of the popup column to > arrangedObjects will correctly display the object's chosen display field > data (for lack of a better descriptor) for each of the rows in the > collection - "selection" will not. Selection only displays the value that > is currently selected in the popup, regardless of the underlying data, and > the same value is then displayed across all the rows.
Where do you get the idea that "selection" is singular? It's a proxy object for the controller's selection. That's why the docs explicitly tell you to bind through it rather than selectedObjects; it's faster to provide the proxy than build the array of model objects. >> Why are you binding "Selected Object" to a collection of objects? >> Typically the Cocoa controls automagically set up their selection >> bindings when bound to a controller anyway. This is something that I >> have not seen documented, but that Apple employees on this list have >> confirmed. I know it's true for NSTableColumn. > > Are you saying that I don't need to bind the Selected Object of the popup at > all? This is contrary to what I've seen in the samples. I'll give it a > shot though as it is easy enough. Sure enough, it isn't true for NSPopUpButton. But is it really that hard to write a method and wire up the popup button to it? > Interestingly enough, the Core Data dox state that when SQLite is used as > the store, in a many-to-many relationship, the intermediary table is > automatically generated (which is the behavior I expect). This is really an implementation detail. It's there to assure you that the Core Data guys know what they're doing. ;-) > The only naming convention "rule" I saw was that names need to begin with > lower case letters (this due to macro facilitation for the creation of > accessors, etc.). I use a naming convention that is particular to my needs, > not the whole world or some purist's notion. What I'm telling you is that your convention gives you incorrect information. > Also, names should indicate > the objects they represent. "tbl," or table, is descriptive enough for me > to know what it is without having to look it up somewhere else. And, isn't > that the real point? What information does that prefix give you that you can't get from the already-declared type? It makes your code difficult to follow, that's for sure. > As a tangent, when doing database design, one begins with "entities" but > those turn into "tables" so, in reality, one is really designing "tables." > Entities are first used to described high-level relationships, but, as one > works "down" into the implementation (going from logical to physical), most > of the time the "entities" become tables or a number of tables. A great > deal of fancy terminology which can sometimes add clarity but then can also > muddy the waters. Just my personal opinion though. Core Data is not a database. I think Entity was a bad naming choice, but Table would have been far worse; for a majority (2/3) of the store types, there are no tables involved whatsoever. --Kyle Sluder _______________________________________________ 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
