Namaste!
Thank you for your reply. See my commentary below.
However, my question still remains unanswered.
Peace, Love, and Light,
/s/ Jon C. Munson II
Quoting Kyle Sluder <kyle.slu...@gmail.com>:
On Fri, Feb 6, 2009 at 3:36 PM, Jon C. Munson II <jmun...@his.com> wrote:
Well, using "selection" didn't work (now that I've had an opportunity to
test it). It definitely needs to be arrangedObjects (or something similar).
So, it isn't that.
"Arranged Objects" is plural. "Selected Object" is singular. It
should be apparent why this is not going to work out, and why you're
winding up with the -description representation of an array in your
popup menu. Table views, on the other hand, support multiple
selection, so the bindings for NSTableView are plural: "Selected
Indexes."
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.
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.
Also, you are aware that Core Data allows for many-to-many
relationships without intermediary entities (they are not called
"tables"), right? I understand you have attached attributes to this
relationship, and you need an intermediary entity in this case.
Yes, Core Data does allow for many-to-many relationships. However,
after a solid week of fooling around with trying to get that to work
(there are only so many permutations one can use), I was not able to
produce a working prototype. Nor did I see any samples that covered
that particular arrangement. You are welcome to give it a shot
though. Create a simple test. Two entities, Person and Hat.
Many-to-many relationship. A person can wear many hats, and a hat can
be worn by many people. I couldn't get this to function w/o an
intermediary entity.
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).
Your naming convention is also rather screwy. It looks like
Bastardized Hungarian (aka "Anti-Hungarian Notation", according to
Larry Osterman:
http://blogs.msdn.com/rick_schaut/archive/2004/02/14/73108.aspx ). It
conveys no useful information; in fact, since Cocoa (and KVO in
particular) rely on the dynamic nature of the ObjC runtime, your
prefixes are lying. And of course, they're incorrect, since there's
no such thing as a "table" in Core Data land. I would suggest ending
your prefixing habit now before you confuse yourself when what you
thought was a "tbl" winds up being an "_NSKeyValueObservingEntity" in
the debugger.
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.
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? Sure,
we could argue what something "really" is, but that may not help you
later - especially if there is a great deal of abstraction going on.
If I had an entity that wasn't a table, I'd give it the appropriate
prefix. Let's not get off on a tangent of naming things as that is
definitely a matter of personal preference. What matters is that the
code is readable, not too cryptic, and you can remember what you did
later down the road with minimal commenting.
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.
--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
