Re: Using Bindings with a Slow-Setting Model
Re: Using Bindings with a Slow-Setting Model
- Subject: Re: Using Bindings with a Slow-Setting Model
- From: Daniel Jalkut <email@hidden>
- Date: Thu, 22 Sep 2005 19:50:56 -0400
Looking a little more carefully at the KVO support in Cocoa, I see
that I can control whether automatic change notifications are sent on
a per-key basis. I didn't realize this before, and I can at least
use this to avoid the icky "double notification" issue I described
below.
I'm still curious whether anybody has any general thoughts about this
type of arrangement. I'm not stuck, but I imagine there is
philosophical wisdom out there to be shared...
Thanks,
Daniel
On Sep 22, 2005, at 6:29 PM, Daniel Jalkut wrote:
I want to use bindings to keep a user interface in sync with a
network-based model. To that end I've wrapped the network model
with an Objective-C object, whose keyed values I bind to my
interface. The problem is that manipulations to the network model
are non-blocking. A "set" on the wrapper model goes out to the
network while execution continues in the client. When the network-
based model acknowledges the set has completed, it returns with a
message indicating that value has changed, and the wrapper's
instance variable is updated to reflect the change.
This type of scenario seems extremely well suited to one of the
"classic" controller arrangements, where the set methods all
operate directly on the model, depending on subsequent
notifications from the model to trigger triggering changes in the UI.
It doesn't seem so well-suited to bindings, because there is an
assumption (or am I wrong?) that setting a property on a model key-
value compliant object is a relatively atomic operation. As it
happens, it sort of "just works" right now, though I believe I'm
abusing the philosophy of bindings somewhat. When my wrapper
object's set: methods are called, nothing actually changes. Later,
when the network object acknowledges the change, I do a manual
"willChange" and "didChange" on the appropriate keyed-value,
triggering a change in the UI. What bothers me slightly about this
arrangement is that, for every set, I'm causing two "changed"
notices - the first when there hasn't actually been any change in
the value, and the second when the network finally comes around.
It's unsettling to me that I have to essentially maintain two
setter methods per keyed value: one that triggers the change, and
one that confirms the change.
Am I fighting to hard to use bindings in an inappropriate setting?
Has anybody else dealt with an issue like this? Is there some
appropriate way to use the "willChange" and "didChange" methods,
stretching them out over an unpredictable amount of time? My
particular concern is for a network based application, though of
course there are other scenarios where setting might not be as
atomic as bindings is accustomed to.
Thanks for the advice,
Daniel
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
sweater.com
This email sent to email@hidden
_______________________________________________
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