Re: Defaulting new entity fields to be same as current selection?
Re: Defaulting new entity fields to be same as current selection?
- Subject: Re: Defaulting new entity fields to be same as current selection?
- From: "I. Savant" <email@hidden>
- Date: Sat, 31 May 2008 10:30:16 -0400
On May 31, 2008, at 3:51 AM, Rick Mann wrote:
I've got an NSTreeController and associated view. I use -
awakeFromInsert to set default values for the entities created as a
result of calling -add.
That's a good place to do that ...
I'd like for one of the fields to take on the same value as the
currently-selected entity.
Okay, that's controller-layer-level logic and perfectly reasonable
(ie, any serious app using Bindings is likely to need to do that at
some point). Point of order, though - "selected instance", not
"selected entity". The distinction is important though the mistake is
easily interpreted in this context.
Can I get at that from within -awakeFromInsert?
Yes, through some incredible acrobatics, you probably could, but
then that would be like walking right up to the MVC design pattern and
b**ch-slapping it right in the face. ;-)
The model layer is *not* where this belongs. Why should some
instance of your Foo entity care about whether some other instance is
selected in some random controller? That kind of logic belongs in the
controller layer. A controller is in the best position to know what's
selected and what should happen when a new instance of Foo is created.
Must I create my own -add?
Yes. The best place to put this custom -add: action is up to you
and your design (as long as it's in a controller), but
NSObjectController (such as NSArrayController or NSTreeController) in
charge of the Foo instances, I'd do it this way:
1 - Place your user-level action (what's fired as a result of a button
or menu action when the user wants to add a Foo) in some primary
controller. This would be your app controller if it's a "Cocoa
Application" or your [persistent] document controller if it's a "Cocoa
[Core Data] Document-Based Application". If it's a top-level user
interface action, a good design (IMO) is to have all user actions
funnel through one controller for clarity (to the developer).
2 - In a custom NSTreeController subclass specifically suited to all
the "library management" of your Foo instances, create a custom -
addFooWithNameOfSelectedFoo method (also gives clarity) that is called
by your user-level -add: action. This method simply asks "self" for
the currently selected Foo instance, then creates and modifies the new
Foo instance to taste. This Foo-centric NSTreeController contains all
the logic for dealing with your Foo objects, such as -
allFoosBelongingToBar: or -removeFoosOlderThanDate: or -fooWithID:
etc. In this way, it's now your "Foo Library Manager" and when it
comes to Foos, it knows best.
--
I.S.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden