Re: Table views with different NSArrayControllers sharing the same data object...
Re: Table views with different NSArrayControllers sharing the same data object...
- Subject: Re: Table views with different NSArrayControllers sharing the same data object...
- From: Adam P Jenkins <email@hidden>
- Date: Thu, 28 Feb 2008 10:47:28 -0500
On Feb 28, 2008, at 5:46 AM, Keith Blount wrote:
Many thanks for your reply. I have a model object and a view object
- DataList and DataListView. DataList has a -content array. The
DataListView has an array controller whose contentArray is bound to
the DataList's content array. Given that it is the view that
observes the model, I have implemented -
insertObject:inContentAtIndex: and -removeObjectFromContentAtIndex:
in the *view* object, and in these methods it sets itself up as an
observer for newly added list objects. This works fine when there is
only one data list view. But if there are two views that both use
the same DataList object's -content array, this means that each view
is *only* set up to observe items that *it* adds; it will not
observe items added by the other view. So, the second view won't
notice when the first view adds another item to their shared content
array and therefore won't update until you, say, sort the table, and
then it won't observe any changes made to that object, either.
If I move the -insertObject:inContentAtIndex: etc methods to the
model object, though, then I can't add the view as an observer to
the inserted objects as the model knows nothing of the views. Unless
I need to implement these methods in both the view *and* the model,
the view's implementation calling the model's version of these
methods... Given that both the view and the model have a -content
array (the view's -content array is just a retained pointer to the
model's -content array), maybe this is what I need to do?
As I say, my aim here is to have the same content array used in two
table views that update so that they are identical when either
manipulates the underlying data, to account for the situation where
the user may create a split view in my app with the same table list
open in both panes.
Thanks again and all the best,
Keith
Of course it's true that the model objects shouldn't know anything
about the view. My point was that if your model object implements
proper Key-Value coding methods for the content property, then each
controller can register as an observer of the model's content property
to be notified when new content objects are added or removed, and
respond appropriately, for instance by adding itself as an observer to
the new content object. Maybe I'm wrong, but it seems to me that the
problem is you're assuming that if you setup an observer for your
DataList.content property, the observer will only be notified if the
whole content array is replaced. However that's not the case: if
DataList implements the proper indexed accessors, then the observer of
the DataList.content property will also receive notifications of type
NSKeyValueChangeInsertion, NSKeyValueChangeRemoval, or
NSKeyValueChangeReplacement when items are inserted, removed, and
replaced from the content array.
So if I understand correctly, DataList is your model object, and it
has an array property called "content". So assuming your DataList
class implements indexed accessors for the content property, as
described here:
http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueCoding/Concepts/AccessorConventions.html
then you could subclass NSArrayController and in your subclass have
code like this:
DataList *dlist = somehow get hold of the DataList for this controller;
[dlist addObserver:self
forKeyPath:@"content"
options:(NSKeyValueObservingOptionNew|
NSKeyValueObservingOptionOld)
context:NULL];
Multiple controllers can register as observers. Your controller would
also need to implement
observeValueForKeyPath:ofObject:change:context:, which would get
called whenever the DataList's content property was changed, including
having objects added or deleted from it. The
observeValueForKeyPath:ofObject:change:context: method could then
handle new objects being added by registering as an observer, and
objects being deleted by unregistering as an observer. See Apple's
Key-Value Observing Programming Guide for more details.
_______________________________________________
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