Re: Bindings paradigm
Re: Bindings paradigm
- Subject: Re: Bindings paradigm
- From: Gwynne <email@hidden>
- Date: Sat, 10 Jul 2004 18:20:55 -0400
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? :)
A further thought: Again in example, the keys "isOKButtonEnabled" and
"isAnyFlagSet" could be the same thing, but one represents View state
and the other represents Model state. Does something as simple as how
the keys are conceptualized resolve the issue?
-- Gwynne, key to the Code that runs us all
Email: email@hidden
Web:
http://musicimage.plasticchicken.com/
_______________________________________________
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.