Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- Subject: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- From: mmalcolm crawford <email@hidden>
- Date: Mon, 3 Jan 2005 13:21:50 -0800
On Jan 3, 2005, at 12:34 PM, Mark Munz wrote:
On Jan 3, 2005, at 12:29 PM, mmalcolm crawford wrote:
On Jan 3, 2005, at 7:58 AM, Mark Munz wrote:
I agree 100%. Users expect magic (things just work the way the
expected it to), but programmers need to be able to step through
each piece to insure the results are expected (and that the
unexpected is dealt with). I get the whole KVC, KVO concept. That's
not what bugs me with bindings. It's the magic, in particular with
NSArrayController that I've struggled with.
There is no magic.
Of course there is no magic, but if the behavior is non-obvious and
without understanding, the results appear to be magic.
This is not an issue that is unique to bindings (and Arthur C. Clarke
got there a long time ago...).
I would argue that setting up basic default behavior with the option
to override would work, just like sorting. Perhaps provide a
DNDDescriptor that answers the questions mentioned: Pasteboard Name,
Allow Reordering, Pasteboard Types, etc. I know that many times, my
tables are represented as NSArray of NSDictionary. It even looks like
DNDArrayController could be close to the expected default behavior.
that's the same argument used for NSArrayController now. Most of the
time, we're writing the same basic glue code.
Fair enough, please file an enhancement request.
As has been stated on several occasions on this list, because
bindings rely largely on key value coding, strings do not work well
as a model. Typically you need at least a dictionary.
OK - I think this may be at the heart of my problems. I did search the
list archives, but apparently not on the right keywords. I found the
discussions on using NSDictionary instead of NSString. My main use
right now for bindings is the deal with Arrays of Strings. So is the
best solution to convert all my NSArray of strings to NSArray of
dictionaries? Or some other wrapper object? So I have to change my
model so that I can using bindings? I saw a message by Daryn that
mentions adding KVC support to NSMutableString (via Categories).
You can either create categories of NSString/NSMutableString, or use
dictionaries.
Is there a bottleneck for NSArrayController other than
arrangedObjects? Perhaps just subclassing NSArrayController to map the
NSString array would work.
It's probably easier to use dictionaries.
Again, if you would like to use strings, please file and enhancement
request.
Essentially, an example of a basic List. Start off without
drag-n-drop support. Then add it.
That's basically what my Bookmarks example does. If you want to
remove drag and drop support, simply revert the DNDArrayController to
an NSArrayController.
When I said a basic list, I was referring to a single column list.
Well, there's no conceptual difference between a single and and
multi-column list...
Because the Bookmarks example has multiple columns, there is no
mention of the problem with NSArrayControllers and NSString. The use
of NSDictionary is a natural one in that case (because you have
multiple columns). That's where I think I kept getting thrown off.
... and strings didn't feature because of the issue raised above.
Finally FWIW, if the intent is to reduce code, I think there should
be a way to support basic properties without having to write the
glue code to access each one property.
It already does:
<http://developer.apple.com/documentation/Cocoa/Reference/
Foundation/ObjC_classic/Protocols/NSKeyValueCoding.html>
I must be missing something, because the answer does not seem obvious
based on this. Are you referring to accessInstanceVariablesDirectly?
setValue:forKey:
[... if ] (no accessor method is found), if the receiver's
accessInstanceVariablesDirectly class method returns YES [the default],
searches the class of the receiver for an instance variable whose name
matches the pattern _<key>, _is<Key>, <key>, or is<Key>
valueForKey:
If an accessor method is not found valueForKey: searches for an
instance variable based on key and returns its value directly.
mmalc
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden