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: Thu, 28 Jun 2007 21:36:03 +0200
OK, thank you very much.
You're most welcome.
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.)
Yes, that's one approach. Keep in mind, however, that NSViews are
"heavy" objects, carrying a fair amount of "baggage", meaning that if
you have a lot of them in a single window, your application may be a
little sluggish.
If you need to have a lot of items that should respond to user
interaction, it's more efficient to define a single master controller
for the view where your elements reside. Then, when the user clicks
on, or drags through, the view, the view tells the controller where
these mouse events happened.
The controller then uses your data model to perform all the necessary
logic to decide how each of your elements should behave/respond,
passing that information back to the view. The view then takes care
of actually moving, resizing, and otherwise manipulating the visual
aspects of your elements.
Notice how, in this way, the elements themselves don't have to be
NSView instances and, additionally, note how the controller knows
nothing about the visual aspects of the elements and the NSView
instance "hosting" the elements knows nothing about the model data
underlying the elements. All responsibilities are neatly separated.
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?
Yes. What you described is a simplified version of what I described
just above.
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?
It sounds fine to me. If you don't need more than one document, why
have to deal with all the extra functionality (and associated
headaches!) that come with the multiple document architecture?
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