Re: NSTableView Popup Column issue
Re: NSTableView Popup Column issue
- Subject: Re: NSTableView Popup Column issue
- From: Kyle Sluder <email@hidden>
- Date: Sat, 7 Feb 2009 14:37:54 -0500
On Sat, Feb 7, 2009 at 1:05 AM, <email@hidden> 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 (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