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.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
