Re: NSUndoManager in non-document based app using bindings
Re: NSUndoManager in non-document based app using bindings
- Subject: Re: NSUndoManager in non-document based app using bindings
- From: Dirk van Oosterbosch <email@hidden>
- Date: Wed, 15 Sep 2004 21:51:18 +0200
On 15-sep-04, at 13:11, Patrick Machielse wrote:
The way to do this in IB (I believe) is to first instatiate an
NSObjectController to expose the properties of your model object, and
then
bind an NSArrayController to this object controlller.
...
You don't _have_ to instantiate the account in IB. In the object
controller's inspector Attributes pane you can specify the 'Object
class
name' and flag 'Automatically prepares content', to have your model
instantiated on the fly by the controller.
I do not fully understand this approach. I have the 'Object class name'
of the NSArrayController already as the model, the basic model that is,
Expense. The ExpensesAccount class on the other hand holds the
MutableArray full of Expenses. I am still not sure if I should consider
this class a model or a controller. I believe the ExpensesAccount
starts to act a whole lot more like a controller to me: it now contains
the code for Undo & Redo, and for loading and saving, *and* it is
connected to other stuff in IB.
On 15-sep-04, at 19:38, mmalcolm crawford wrote:
Probably the only relevant differences here between a document-based
and a non-document-based application are:
(a) As you discovered, you'll probably have to create some bindings
programatically;
(b) NSDocument provides an NSUndoManager for you.
NSDocument's undo manager is just an instance variable accessed using
accessor methods. If you're not using NSDocument, your application
controller should provide an undo manager in a similar way.
How you use and integrate with the undo manager should be the same in
whether the app is document-based or not.
Well, I've gotten the UndoManager to work now, but I have to admit it
is ugly. I gave the ExpensesAccount class an IBOutlet to NSTableView
and connected it in IB. Then I asked it (the NSTableView, which is
controlled by NSArrayController, right?) for an undomanager and
implemented the undo functionality in ExpensesAccount using that
manager. I don't like it, though, for it doesn't look like decent MVC
design at all. But hey, it works!
Should I consider such an ExpensesAccount class a controller, then? And
what would be the correct relation between all those controllers? (1.
AppController as delegate of NSApp, telling ExpensesAccount to load and
save; 2. this ExpensesAccount holding the MutableArray and 3.
NSArrayController controlling the TableView). Or should I move code
away from ExpensesAccount and put it in AppController?
Right now it seems rather messy. (but maybe that only in my head ;-) ,
my application doesn't seem to bother ...)
Thanks.
Dirk
_______________________________________________
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