Re: Core data, NSArrayController and different nibs
Re: Core data, NSArrayController and different nibs
- Subject: Re: Core data, NSArrayController and different nibs
- From: Tomaž Kragelj <email@hidden>
- Date: Fri, 7 Nov 2008 08:43:33 +0100
On 6.11.2008, at 11:45, Cathy Shive wrote:
On Nov 6, 2008, at 8:50 AM, Tomaž Kragelj wrote:
It looked so trivial at the start, but didn't work as expected - my
single window application uses the following setup:
- MainMenu.nib: my AppController and all the NSArrayControllers
with bindings set properly so when an item is selected in the
master controller, it's details are handled by children controllers
(all data comes from managed context).
- MainWindow.nib: the main window with placeholder view (and the
rest of the common user interface).
- CustomView.nib: the actual views are implemented each in a
separate nib and are then moved as child view in the main windows
placeholder when necessary (similar to Apple's ViewController
sample).
The problem I have is that the custom views need the data from the
array controllers defined in MainMenu.nib. It seemed logical to
create outlets to the array controllers in my AppController and
expose them through accessors to the rest of the controller layer.
Something like this should work :)
Yep, it does now (see below)...
In my custom views I would then bind the controls to these (like
Application.delegate.arrayController.arrangedObjects.key for
example). But this doesn't work - the bindings are ok, there's no
error, but I get no data.
The custom view here is a table view, right? I'm just guessing, but
if this is the case, then I think the issue is that NSTableView
wants (neeeeds) to be bound to an array controller - not the app
delegate - even if the key path leads it to an array:
http://www.cocoabuilder.com/archive/message/cocoa/2008/7/17/213304
In this post, it is suggested that Ivy put her array controller back
in the nib with the view ;) That is exactly the opposite of what
your trying to do with your refactoring project. Someone else
suggests using a proxy array controller as you've described.
I'd just do the binding in code so that you can maintain the design
you're after until someone fixes this "bug" with NSTableView (I call
it a bug, the key path should be good enough for the view to
establish the binding!) Anyway, it's just one line of code vs.
setting up more array controllers.
In one case it is table view, but it worked using proxy array
controller (albeit the selection was not reflected in the main array
controller). However the case that made me problems was using a custom
view for drawing charts.
After all I decided to take manual route. First I changed the table
view controller - I made the view controller the data source and I
manually fill the table. But the table was empty. The problem was, as
I discovered, in the timing. The table automatically reloaded itself
during awakeFromNib, but the controller data was not yet fetched from
core data at that time. So I setup the KVO for the array controller
(through representedObject) for arrangedObjects key path. Inside I
send reloadData to the table view. This works as expected. Then I
needed to do the other synchronization such as initial table view
selection, handle table view's selected row change and update the
array controller etc. Now it works like a charm. Also the code is not
so bad (especially since it is encapsulated within the view controller
and doesn't clutter the window controller, plus I need some code
anyway because I use custom table view cell to do specialized
drawing). But I do feel that IB solution would be far more elegant and
less error prone...
And for my custom chart view I also take the same solution. Now the
selection in the main table view reflect the data which is shown in
the charts. At the same time my custom view nibs don't need proxy
controllers which I felt only added to the confusion and presented
problems like synchronizing selection from proxy to "main" controller
(didn't work by itself).
Thanks, Tom
_______________________________________________
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