Re: Initial value of on/off buttons

FROM : Yann Disser
DATE : Sun Apr 27 11:59:11 2008

Ok, I finally solved my problem...

I do NOT need an NSObjectController! Perhaps you got me wrong about 
what I tried to accomplish.

The problem was, that I was binding the value of my buttons to bools 
that did not directly belong to my controller class but to an 
attribute of my controller class: "attribute.bool" was my model key 
path.

The problem was that I initialized attribute with "attribute = 
[AttrClass new]" in awakeFromNib instead of "[self setAttribute:
[AttrClass new]]".

Thanks anyway for your help!

Yann


On 26. Apr 2008, at 5:26, I. Savant wrote:

> On Apr 25, 2008, at 7:37 PM, Yann Disser wrote:
>

>>> Are you binding via an NSObjectController?

>>
>> No, should I?
>>

>
>  Yes (or one of its subclasses). You have to make sure "everyone is 
> on the same page" as mindless corporate and government automatons 
> are wont to say. In Cocoa, this is done easiest (usually) with 
> Bindings:
>
> http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaBindings/Concepts/HowDoBindingsWork.html#/
> /apple_ref/doc/uid/20002373
>
>  Since Cocoa follows the Model-View-Controller design pattern:
>
> http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/chapter_5_section_4.html
>
>  ... and the Bindings mechanism relies on the Key Value Coding and 
> Key Value Observing mechanisms:
>
> http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueCoding/KeyValueCoding.html
>
> http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueObserving/KeyValueObserving.html
>
>  ... this means that yes, your boolean values can be bound to things 
> (or things can be bound to your boolean value) but both sides of the 
> relationship must play by the rules to get things observed and/or 
> respond to the things you're observing.
>
>  Considering the above (if you believe such edicts), that should be 
> done by the controller layer, which is in the best position to 
> mediate between your model (state, persistent or not) and your view 
> of that model. Your controller just has to send the right signals to 
> get changes noticed.
>
>  Without this, you'd have to do something ridiculous. Something like 
> making a checkbox know how to track whether that picture of your 
> grandma doing shots of Jägermeister and showing her tongue piercing 
> at the local strip club is included in an album you happen to be 
> publishing on photobucket.com and sharing with the good folks at 
> First Baptist Church.
>
>  Where was I? Oh.
>
>  We don't need a checkbox that specific. Just a checkbox that 
> reflects a boolean state. We also don't need to photo to know 
> anything about albums and photobucket.com and grandma's questionable 
> habits. That particular state in that particular grandma-busting 
> application is shared with a property of some 'picture' object ... a 
> boolean property called 'includedInAlbum'. The controller is 
> responsible for matching the checkbox to the 'included' state of a 
> picture to an album.
>
>  That controller executes the 'application-specific' logic that 
> makes that particular checkbox affect the 'includedInAlbum' state of 
> that particular picture (depending on your selection and latent 
> anger toward your grandmother). Make it do your will and thank you 
> for the privilege - but respect its existing talents - and leave the 
> rest to do what they were designed to do.
>
>  So ... bind your button (view) to your model (whatever that boolean 
> represents) via their common mediator - a controller. Depending on 
> your needs, a generic NSObjectController, an NSDictionaryController, 
> or the more container-like NSArrayController will handle most 
> general cases with ease. NSTreeController ... well NSTreeController 
> is ... available.
>
>  Now a standard disclaimer: I apologize if any of that is unclear, 
> incomplete, or just wine-drunken rambling. It's Friday.
>
> --
> I.S.
>