Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- Subject: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- From: Roarke Lynch <email@hidden>
- Date: Fri, 7 Jan 2005 23:43:09 -0500
On Jan 6, 2005, at 1:45 PM, Charlton Wilbur wrote:
With this, you can *completely* emulate result = [a isGreaterThan: b] with KVC calls:
[a setValue: b forKey: @"isGreaterThan"];
result = [a valueForKey: @"isGreaterThan"];
I have to step in on this one. I've been reading this thread with interest and I think with this line the topic has gone way over the deep end. I think of KVC / KVO as an acknowledgment of three general facts:
(a) The model object will tend to have members that can be thought of as properties or attributes.
(b) These members will tend to have a common syntax related to their accessors and mutators.
(c) View objects tend to have and set values directly tied to these members (more specifically the related accessors and mutators)
With this in mind if you model your objects (as most of us do) with this syntax you can cut down on that most dreaded foe: glue. Binding expressions are just short-hand to method invocation. Binding a view to a model with the expression
name just says that to the view: when you need a value invoke a method called
name or
getName pass it though a value transformer (if specified) and take that value as your own and vice-versa when you change your value to take that value, pass it though a value transformer (again, if specified) and invoke a method called
setName with this value as the argument. KVO allows the view to know when it needs to update and allows the model to know when it needs to. Expression paths such as selectedObject.name just allow that process to tread more deeply into models without needing mediation.
Its great.
Now don't get me wrong, I wish it's implementation was a lot more robust. I wish i could see all graphically within IB, I wish that IB had a greater knowledge of what keys were permissible before runtime, but on the whole I think it works well because it recognizes a generality and uses this fact to reduce the related commonality of the glue needed to tie everything together.
Roarke Lynch
-------------------------------
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
| References: | |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Philippe Mougin <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Charlton Wilbur <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Philippe Mougin <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Charlton Wilbur <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Philippe Mougin <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Charlton Wilbur <email@hidden>) |