Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- Subject: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- From: Mark Munz <email@hidden>
- Date: Mon, 3 Jan 2005 14:34:51 -0600
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.
In my opinion, the fact that basic operations like Drag-n-Drop still
require "glue code" defeats the purpose of a general purpose array
controller.
In some respects drag and drop may be considered "simple", however
there are a number of combinations of operation that one might want to
perform, or not depending on the circumstances. Do you allow
reordering? What pasteboard types do you allow? What actually
happens on a drop (how do you retrieve what from the pasteboard, if
indeed you do)? The existing table view delegate methods give a
reasonable abstraction that allows customisation of all of these
behaviours; I suspect that there would be complaints if bindings
forced you to adopt a single model...
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.
I can get stuff to work, but I don't understand why the stuff I got
to work does what it does. It's very click-and-pray. I've would love
to see an example of NSArrayController with just one basic type --
NSStrings.
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).
Is there a bottleneck for NSArrayController other than arrangedObjects?
Perhaps just subclassing NSArrayController to map the NSString array
would work.
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.
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.
There is also a general flaw with using Interface Builder to develop
applications -- there are no diagnostic tools that easily show
connections (Outlets and Actions and Bindings) for each object. You
essentially have to click on each object and view the connections,
bindings individually.
Please file enhancement requests...
Already Done.
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?
I do want to understand this. I will dig through the examples again
with the new understanding that NSArrayController does not like simple
NSObject arrays but rather more complex objects like NSDictionary.
Perhaps that will help me shed the light on this whole area.
Mark Munz
_______________________________________________
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