Re: Use UI or data for logic? (hijacked from Two NSRects adjacent/touching?)
Re: Use UI or data for logic? (hijacked from Two NSRects adjacent/touching?)
- Subject: Re: Use UI or data for logic? (hijacked from Two NSRects adjacent/touching?)
- From: Paul Bruneau <email@hidden>
- Date: Thu, 28 Jun 2007 14:00:51 -0400
On Jun 27, 2007, at 9:23 AM, Wagner Truppel wrote:
NSRect is not a class, but merely a struct. Thus, NSRects are not
objects, so they don't respond to messages. NSView is a class that
inherits from NSResponder, the class which defines the behavior for
objects that respond to events (such as mouse clicking).
OK, thank you very much. I do recall reading that but had forgotten
it in my newbness. So it could be reasonable to have my elements be
instances of NSView so that they can respond to clicks and drags more
automatically? (to review, my app will be a scheduler made up of
Gantt charts that can be manipulated by the user.)
One of the main paradigms on which Cocoa is based is the Model-View-
Controller architecture, according to which you should separate the
logical behavior of your application's objects from their visual
representation. In other words, do the logical processing outside
of the user interface. It will simplify your life in the long run
by making it easier to maintain your application. It's also more
efficient.
So could someone let me know if I am near the mark with this thinking:
user begins dragging element -> controller determines where element
can be dragged based on data in the model -> controller communicates
to the element the limits of where it can be dragged -> when element
is dropped the controller is informed and updates the data in the
model appropriately
something like that?
You might want to read
http://developer.apple.com/documentation/Cocoa/Conceptual/
CocoaFundamentals/CocoaDesignPatterns/chapter_5_section_4.html
for more details.
OK thank you again. I will aim at doing all the logic in the
controller, keeping the data in the model and the UI in the view. I
would like to (for once) do things the right way.
I am planning on NOT using a document architecture (our company will
have only one schedule). Does that sound stupid to anyone?
_______________________________________________
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