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: Wagner Truppel <email@hidden>
- Date: Wed, 27 Jun 2007 15:23:41 +0200
This is how I am used to doing things procedurally (my only
programming experience to date), but I was thinking that with Cocoa
things would be a little different. I expected my rect shapes to
generate their own messages upon being clicked. Don't the elements
of a NSView get "told" that they have been clicked by the OS? Then
based on their outlets (if I am using the term correctly), the
desired code gets called?
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).
This part of Brad's question also has me wondering about something.
I am torn and ignorant about whether to use the NSView and its
elements to determine decisions, or whether to use the underlying
data to make my decisions.
For instance, the user will want to drag a rect (representing a
task to be completed) either forward or backward on the
"timeline" (left or right). But she might be limited by other tasks
being "in the way". Or maybe I want the user to be able to "nudge"
other rects out of the way with the one that she is dragging
around. Should I use the actual rendered graphic rects to determine
when such collisions occur, or should I rely only on the underlying
data to find these collisions?
I want the user to be able to zoom in and out of time as desired.
Since the UI should be scaled correctly and it seems very handy to
use, I would like to go that way, but it seems to go counter to the
idea of separation between the UI and the data--part of me thinks I
should do all computations purely in the data, and use the UI only
for UI things, not for determining logic.
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.
You might want to read
http://developer.apple.com/documentation/Cocoa/Conceptual/
CocoaFundamentals/CocoaDesignPatterns/chapter_5_section_4.html
for more details.
Wagner
_______________________________________________
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