Am Do,21.08.2008 um 08:58 schrieb Oleg Krupnov:
I need to make the design decision regarding how the model and the
views will be kept in sync with each other. Namely:
- I can use key-value coding and observing (KVC and KVO)
- I can use bindings (not sure if it's really different from the KVC/
>> I suspect that it could be way easier, when a property's value
>> changes, to just explicitly send a concise and clearly named message
>> to the subscribed objects,
>
> This is, what is done. The name of the message is
> -observeValueForKeyPath:ofObject:change:context:
Then how is it better tha
Am Do,21.08.2008 um 15:22 schrieb Oleg Krupnov:
I suspect that it could be way easier, when a property's value
changes, to just explicitly send a concise and clearly named message
to the subscribed objects,
This is, what is done. The name of the message is
-observeValueForKeyPath:ofObject:cha
Thanks Amin for responding.
You are correct that there's no need to reinvent the wheel, and that's
exactly what I'd like to avoid, that's why I am now re-reading about
KVC/KVO and reconsidering it.
So, does everybody really always use KVC/KVO for implementing MVC, in
all projects? Is this the rec
Am Do,21.08.2008 um 16:41 schrieb Oleg Krupnov:
Thanks Amin for responding.
You are correct that there's no need to reinvent the wheel, and that's
exactly what I'd like to avoid, that's why I am now re-reading about
KVC/KVO and reconsidering it.
So, does everybody really always use KVC/KVO fo
Amin,
It is true that I am new to Cocoa, and although I find the
documentation really great and engaging, I have sort of difficulty
figuring out what technology is newer/more powerful/built on top of/
other technology.
In particular, would you explain me, in just two words, what are the
relations
Oleg,
by all means, go ahead with what you started and spend more time
learning about KVC/KVO.
Yes, this is used in many many projects and I personally would really
miss it if it wouldn’t be there. Actually, as you described yourself,
if it wouldn’t be there, you’d had to brew something s
Am Do,21.08.2008 um 17:03 schrieb Oleg Krupnov:
Amin,
It is true that I am new to Cocoa, and although I find the
documentation really great and engaging, I have sort of difficulty
figuring out what technology is newer/more powerful/built on top of/
other technology.
In particular, would you e
I love answering questions that require an essay. So here is my essay.
I think my forthcoming Cocoa Design Patterns book does a good job of
explaining the patterns used to implement Cocoa and reused to implement Cocoa
applications. In particular, the book explains how techniques like Key
I have some quibbles...
On Aug 21, 2008, at 12:54 PM, Erik Buck wrote:
So, in summary, the whole point of KVC is to standardize the way an
object’s properties are accessed regardless of how they are stored.
Well, the real point, to my mind, is to increase the dynamism of
property access.
Remember that NeXT and Apple didn't just invent KVC, KVO, and Bindings
out of thin air for no better reason than they were enamored of the
idea.
There was a substantial history of NeXTStep/OpenStep/Cocoa programs
written. The developers at NeXT and then Apple recognized that there
was a
On Aug 21, 2008, at 7:12 PM, Ken Thomases wrote:
I have some quibbles...
On Aug 21, 2008, at 12:54 PM, Erik Buck wrote:
So, in summary, the whole point of KVC is to standardize the way an
object’s properties are accessed regardless of how they are stored.
Well, the real point, to my mind,
On Aug 21, 2008, at 7:09 PM, Erik Buck wrote:
On Aug 21, 2008, at 7:12 PM, Ken Thomases wrote:
On Aug 21, 2008, at 12:54 PM, Erik Buck wrote:
KVC also provides support (hooks) for change management so that
any change to a property can have application defined side effects
like registering
On 22 Aug 2008, at 1:03 am, Oleg Krupnov wrote:
4) Anything else I may have overlooked?
I've read through this thread and it's very interesting.
But one thing that has been overlooked - common or garden
notifications. If all you want is to pick up a change in an object a
notification is
So, does everybody really always use KVC/KVO for implementing MVC, in
all projects? Is this the recommended best practice?
From code written after 10.2, yeah, pretty much. Coupled with the
tools support in Interface Builder and the AppKit support with Cocoa
Bindings, it's really not worth t
On Thu, Aug 21, 2008 at 10:27 PM, Graham Cox <[EMAIL PROTECTED]> wrote:
> But one thing that has been overlooked - common or garden notifications. If
> all you want is to pick up a change in an object a notification is a simple
> way to do it without writing your own messaging system. It's less pow
On Fri, Aug 22, 2008 at 3:59 PM, Kyle Sluder
<[EMAIL PROTECTED]> wrote:
> @implementation ToolBar
> {
>-(id) init
>{
>[[[NSNotificationCenter] defaultCenter] addObserver:self
> selector:@selector(splitViewResized:) object:mySplitView];
>}
-(void)dealloc
{
[[NSNotificationCe
On 22 Aug 2008, at 2:22 pm, Phil wrote:
Why use NSNotifications when there's already
perfectly good notification mechanism?
Indeed, but notifications have been around a lot longer than KVO, so
there are still plenty of places in Cocoa that notifications are used
for legacy reasons.
Als
18 matches
Mail list logo
