Re: NSImageView and CoreData entity creation
Re: NSImageView and CoreData entity creation
- Subject: Re: NSImageView and CoreData entity creation
- From: Eric Friedman <email@hidden>
- Date: Sun, 18 Sep 2005 09:26:21 -0700
On 9/18/05, Eric Friedman <email@hidden> wrote:
> On 9/18/05, Chris Hanson <email@hidden> wrote:
> > On Sep 17, 2005, at 8:55 AM, Eric Friedman wrote:
> > Finally, one could always introduce an intermediate controller object
> > (not necessarily an NSController) to handle the NSImageView
> > associated with a Person's Picture without subclassing NSImageView
> > itself.
>
> Could you please explain this one further -- I'm not clear on what you
> had in mind.
I think I've got this worked out, and in the process came to an
interesting conclusion. (Short version: inferring relationship
changes from attribute edits is not a good idea -- lazy creations are
doable, but lazy deletes may lead to user-befuddling idioms.)
As Chris suggested, I wrote a controller object that exposes an
attribute - (NSData *)pictureData. I instantiated this object in my
nib file and gave it an IBOutlet connection to the NSArrayController
of people, so that it can track the selection of people.
I then made my controller a KV observer of the people arraycontroller
(for the selectedObjects key) so that I'd know when it was time for
the pictureData attribute to change.
Since I needed to tell my controller's observers (specifically, the
NSImageView, which binds its data attribute to my controller's
pictureData) that pictureData changed, I needed to implement manual
KVO support for pictureData. That made it possible for my controller
to send the willChange/didChange messages to observers about
pictureData whenever the change to the array controller's selection
was observed. This step was necessary because automatic notification
would only get posted on a setPictureData, and my controller doesn't
call that when observing a change to the array controller selection.
I do, of course, post willChange/didChange from setPictureData so that
observers get notified when an image is dragged/dropped in the
NSImageView. In that method, I look at the inbound NSData object --
if it's nil, the user cut (deleted) the image and I need to clear the
relation. if it's non-nil, the user set the image and I need to
create the relation and set the data attribute.
in the pictureData accessor, I do the opposite -- traverse the
selected person's picture relation and, if it's not-nil, return its
data.
So all of this works fine (thanks Chris!), BUT I realized while
working through it that although lazily instantiating the picture
relation is nice, deleting the relation (as opposed to the picture
data on that relation) is not so great. After all, the reason that I
have this modeled as a relation in the first place is that it's more
than just an attribute -- Picture has attributes of its own, including
caption. So, intercepting image view edits is not really an
appropriate way to manage that relation, because it would mean
throwing out all of those attributes when only the image was deleted.
Not hard to imagine circumstances in which users would find
that...upsetting.
The only sensible thing to do in this deletion case is to leave the
Picture relation unmolested and just delete the attribute that holds
the image data. In that case, it's probably not worth worrying about
special casing the *creation* of the picture relation either. So, my
thinking is that I should just have Person allocate a Picture during
-awakeFromInsert and be done with it.
In sum, it would've been nice if I'd figured this out sooner (and
Chris and the coca-dev achives certainly tried to tell me as much),
but it was a good learning exercise -- I hope someone else benefits
from this summary.
Thanks again to Chris for the suggestions.
Eric
_______________________________________________
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