Re: Cocoa Bindings - many people using them?
Re: Cocoa Bindings - many people using them?
- Subject: Re: Cocoa Bindings - many people using them?
- From: Jim Hagen <email@hidden>
- Date: Fri, 21 May 2004 15:45:45 -0700
On May 21, 2004, at 1:18 PM, Steve Sims wrote:
There's a few slightly limitations though. Whilst you can put a list
of parameters for "enabled" or "hidden" I believe (if memory serves)
this list is logically ANDed - i would have liked to be able to enable
on one condition OR another. There's probably a way around this
limitation though using value transformers. Bindings also (for text
fields at least) don't
A "NSNegateBoolean" transformer ( one of the three built-in
transformers ) will give you "NOT foo", so you could construct a
similar logical statement, though it might get a little tricky.
Creating an "isFooEnabled" boolean in your model and binding the
visible/editable parameters to that works well when using multiple
other booleans doesn't. Such a boolean might make sense for your data
model anyway if there's such a dependancy. I always try to think about
making non-UI-based use of the model objects; knowing if you can
successfully invoke a method can be important thing even when there's
no UI.
As for the questions from the original posts, in the context of moving
data from model to view, bindings saves so much code in the
view-controller level that it's pretty difficult to imagine that they
won't get a lot of use for that purpose at the very least. Providing
support for pre-10.3 would be the only reason I can think of to not use
bindings in at least *some* aspect of any new program.
The biggest hurdles to adoption in my view is a lack of "practical"
documentation ( though that's gotten better and as always is seeing
steady improvement ), and a list of things that seem a little too like
"magic", along with things that maybe don't work like you might expect
if it really *was* magic. For example, why doesn't an array send out
notifications for change when something is added to it, or when one of
it's data member's instance values changes? Actually, I know why ( or
at least think I do ), but, wouldn't that be handy, or what you might
expect ? Shouldn't that and other binding/observing issues involving
arrays and key paths be more well documented ( with examples of how you
might avoid such issues ) in general ? Having said that, there probably
is a pretty good description of those issues in the docs, I just didn't
find them in my first read-through and they puzzled me for a few
moments. I've found there are simply some situations where I have to
manually call willChangeValueForKey:/didChangeValueForKey:, but that's
a lot less code than I'd needed to write without bindings.
The benefits of bindings are just too great to ignore; I love 'em.
Writing prototype apps is much faster now that they're available, I
spend a lot less time mucking with UI-update issues. Key-value
observing in general is pretty useful, as well, depending on your
application.
There are of course things that require use of target/action; I have a
table where I need to add columns, which pretty well precludes the use
of bindings ( at least via IB ). But for 'most' uses, bindings can be a
big win.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.