Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- Subject: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- From: mmalcolm crawford <email@hidden>
- Date: Tue, 4 Jan 2005 10:36:16 -0800
On Jan 4, 2005, at 9:33 AM, Izidor Jerebic wrote:
I am sorry if I was unclear. Maybe my last email helped a little?
I'm afraid I'm still not completely sure.
I was looking for an answer to question: "Is it always good to use
Cocoa bindings, and if not, what are the criteria (if they exist)
which tell you when is it wise and when not so to use Cocoa Bindings?"
The answer to the first part is a categorical "No." It's not *always*
good to use Cocoa bindings. There may be reasons not to...
The below excerpt is the best I could come up with. If your object
model does not fit naturally with KVC/KVO (typically objects with
complex behaviour do not fit), it does not make sense forcing it.
... I don't however, believe that this is one of them. I'm still not
sure in what sense you mean than an object "does not fit naturally with
KVC/KVO" -- it's certainly not the case that having complex behaviour
is a typical indicator.
It might be better to write all view-related code (basically code that
would be needed for KVO/KVC) in separate Controller classes, and not
in Model classes.
This again confuses me -- this seems to equate KVO/KVC with
"view-related code". KVO is a system whereby any object may be
notified of changes to another; KVC is a way of accessing the
properties of an object using the property name as a key. Neither is
"view-related".
And, as always, it is a balancing act - you need to decide which path
to take based on specific circumstances.
This is certainly the case. Adopting bindings in an existing
application will require work, typically stripping out existing code,
but it may also involve some re-architecting, primarily of the
controller "layer" if you rely mostly on existing AppKit views, or of
your own custom view classes otherwise. You have to balance this
investment against subsequent code maintainability and UI consistency
correctness.
mmalc
_______________________________________________
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: | |
| | >Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Izidor Jerebic <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Tim Lucas <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Izidor Jerebic <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: mmalcolm crawford <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Izidor Jerebic <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: mmalcolm crawford <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Izidor Jerebic <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Charlton Wilbur <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Izidor Jerebic <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Izidor Jerebic <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: mmalcolm crawford <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Izidor Jerebic <email@hidden>) |