Re: Bindings paradigm
Re: Bindings paradigm
- Subject: Re: Bindings paradigm
- From: "John C. Randolph" <email@hidden>
- Date: Sun, 11 Jul 2004 04:31:09 -0700
On Jul 10, 2004, at 3:20 PM, Gwynne wrote:
On Jul 10, 2004, at 4:41 PM, John C. Randolph wrote:
1) Watch for changes to the relevant keys in code and use [NSButton
setEnabled:].
2) Create a new key in the model object that encapsulates all the
logic and returns the BOOL value (or an [NSNumber numberWithBool:],
it doesn't matter as I understand it), and bind "enabled" to that
key.
#2 is pretty simple, but to me it seems to violate the principle of
KVC because it doesn't represent any data in the model but rather a
state of the view that would have been the controller's
responsibility before bindings came along.
There's really no principle in KVC that calls for a direct
correspondence between keys and actual data in the model. I've
written a category on NSView, for example, that exposes a binding for
"zoom level". The fact that it's derived from the bounds rect of the
view is irrelevant.
So, it's perfectly kosher to make up a key/value combination that
exposes some combination of state in the model.
Good :). However, my concern (not quite expressed correctly before) is
that such keys violate MVC; a Model object isn't supposed to concern
itself with any kind of View state. That's supposed to be the
responsibility of the Controller object. At least, that's my
understanding of MVC :). I recognize that most apps don't follow the
pattern exactly, but I'd like to keep to it as much as possible. As I
understand it, the most correct way by MVC to handle this particular
issue would be to:
1) create a new custom controller object
2) give it an outlet to the Model object
3) create an NSObjectController for the custom controller
4) have the controller expose keys for the Model state, using KVO in
code
5) bind the View objects to the NSObjectController for the custom
controller, or to an NSObjectController for the Model object if the
key doesn't need special logic.
This would isolate the display state logic from the Model data logic.
Or am I just trying too hard to make work for myself? :)
Well, that does look like rather a lot of work.
You do realize that an attribute like "hidden" or "enabled" can be
bound to as many values as you want, don't you? As soon as you bind
"enabled", another binding will appear called "enabled2", and when you
bind that you'll get "enabled3", and so on. So, combining any set of
boolean attributes in your model is all doable in the interface
builder.
-jcr
John C. Randolph <email@hidden> (408) 974-8819
Sr. Cocoa Software Engineer,
Apple Worldwide Developer Relations
http://developer.apple.com/cocoa/index.html
_______________________________________________
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.