Re: How much does NSObject's bind:toObject:withKeyPath:options: do?
Re: How much does NSObject's bind:toObject:withKeyPath:options: do?
- Subject: Re: How much does NSObject's bind:toObject:withKeyPath:options: do?
- From: Matt Neuburg <email@hidden>
- Date: Fri, 22 Sep 2006 20:49:17 -0700
- Thread-topic: How much does NSObject's bind:toObject:withKeyPath:options: do?
On Fri, 22 Sep 2006 17:51:18 +0200, Mailing list subscriptions
<email@hidden> said:
>El 22/09/2006, a las 16:49, Matt Neuburg escribió:
>
>> There are two aspects to this question - theoretical and practical.
>>
>> (1) From a theoretical (perhaps I should say "religious") point of
>> view,
>> this matter has been argued from here to the back of beyond on this
>> list,
>> and you can easily peruse the archives (at cocoabuilder.com) to
>> study the
>> entire sordid history.
>
>I always search the list archives before posting and this case is no
>exception. I searched for "programmatic bindings" and scanned all of
>the results but none seem to match my question; they mostly deal with
>using Bindings with standard Cocoa NSViews.
"I did one search and found nothing, so there's nothing." Fine, I guess that
settles it, and means that you're not interested in being pointed at some
relevant threads?
>
>My question really has two parts:
>
>1. How much work does the default NSObject implementation of
>bind:toObject:withKeyPath:options: do, if anything, or is it always
>necessary to subclass it?
I do not know what it would mean to "subclass an implementation of a
method". If you want to know what a home-made implementation of bind: needs
to do in order to mimic what, say, a checkbox does when you bind it in IB,
see mmalc's GraphicsBinding example.
>2. Is it ok to use bindings to bind between models, controllers and
>other controllers, or is it really only intended for the MVC paradigm
>in its purest forms?
>
>> (2) From a practical point of view, if you want to use bind:... for
>> something and you want to know how your app will behave, why not
>> try it and
>> find out?
>
>At the moment my project is not in a buildable state and it will
>probably be at least a couple of weeks before it is
I didn't say to try it in the app you're working on; I said to try it. You
can (and should) test to your heart's content in a small project that *is*
buildable. You should do this with *any* Cocoa technique you're curious
about, not just this one.
>... but even if it
>weren't, I wouldn't want to embark on this course of action without
>being sure that it's the "right thing" to do. I *know* I can make
>this work with either more or less work, but I don't want to do stuff
>that goes against the intended Cocoa Bindings best practices.
But that is the very matter that I have already termed "religious". By that
I mean that it is not entirely clear that there can be a "right" answer.
All I can do at this point is repeat myself. Argumentation about would
constitute "best practice" appears a-plenty in the archives. (There is also
what I was told by Apple's primary bindings engineer when I explicitly
raised the matter at WWDC. Unfortunately I think it might violate NDA if I
were to recount that interchange here.)
If you want to talk about some *specific* thing you want to do, that might
be a more fruitful approach. For example, my shipping app NotLight uses
bind: all over the place to keep multiple values in sync.
m.
--
matt neuburg, phd = email@hidden, <http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
AppleScript: the Definitive Guide - Second Edition!
<http://www.amazon.com/gp/product/0596102119>
_______________________________________________
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