• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: NSUndoManager in non-document based app using bindings
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSUndoManager in non-document based app using bindings


  • Subject: Re: NSUndoManager in non-document based app using bindings
  • From: mmalcolm crawford <email@hidden>
  • Date: Wed, 15 Sep 2004 13:22:31 -0700


On Sep 15, 2004, at 12:51 PM, Dirk van Oosterbosch wrote:
[...] 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.

If the ExpensesAccount class is basically holding data and "business logic," then it's a model. If it's coordinating between the user interface and a collection of data objects, then it's a controller.


On 15-sep-04, at 19:38, mmalcolm crawford wrote:
[...]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!

I'm not sure why the table view knows about the undo manager?
As suggested in the first reply, the undo manager should almost certainly be a property of the application controller.



Should I consider such an ExpensesAccount class a controller, then?

See above.

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?

Without knowing more about the functionality of ExpensesAccount it's difficult to say.

I think, though, that the Combatants example at <http://homepage.mac.com/mmalc/CocoaExamples/controllers.html> probably gives a reasonable pattern to follow.

mmalc
_______________________________________________
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


  • Follow-Ups:
    • Re: NSUndoManager in non-document based app using bindings
      • From: Dirk van Oosterbosch <email@hidden>
References: 
 >Re: NSUndoManager in non-document based app using bindings (From: Patrick Machielse <email@hidden>)
 >Re: NSUndoManager in non-document based app using bindings (From: Dirk van Oosterbosch <email@hidden>)

  • Prev by Date: Re: NSControlGlyphs generation
  • Next by Date: Re: [Moderator] Cocoa and list resources
  • Previous by thread: Re: NSUndoManager in non-document based app using bindings
  • Next by thread: Re: NSUndoManager in non-document based app using bindings
  • Index(es):
    • Date
    • Thread