Re: Object change to NSView update
Re: Object change to NSView update
- Subject: Re: Object change to NSView update
- From: Paul Bruneau <email@hidden>
- Date: Mon, 25 Aug 2008 09:15:23 -0400
On Aug 22, 2008, at 9:44 PM, Graham Cox wrote:
Keep all of the tree stuff in your data model. When you need to
refresh any given item, flag that to your parent item, which flags
that to its parent item and so on back to the root. The root object
could have one or more controllers which in turn handle the
connections to the views. (Or it could just broadcast
notifications). The root can inform the controller something quite
abstract such as "item 234 needs update!" and the controller can
then pass that on to its view.
Thank you, I feel I am almost there. We are right at the edge of my
ignorance.
I plan to re-read the KVO programming guide with the plan in mind to
set up my controller as an observer to the currently-selected order
(which is the one that is displayed in the custom view)
If the view handles layout it will know how to figure out where item
234 is placed, and mark that area for update. When the view's -
drawRect: method is called, it can discover the items that intersect
the update region, then ask the controller to fetch them from the
data model. The view then draws them however it pleases.
Yes, very good. In this case, the NSView subclass is so simple and
only cares about the currently-selected order, so I just draw the
entire rect upon update.
Ideally, the data model only concerns itself with business logic -
i.e. the relationships between the various entities that you're
modelling. The view(s) could be concerned with layout - so for
example you might have a tree layout view, or a list view. The
controller(s) sit in between and act as a go-between between the
two, so that it can fetch relevant objects from the data model on
behalf of the view, and receive notifications about changes to the
data model and update the view. There's no hard and fast rule about
where the exact dividing lines between the various bits of logic
should go, but in your case I'm thinking that the views should
handle layout which leaves the controllers as a fairly thin layer
that just glues the views and data model together. Note that a
NSTableView (view, performing layout) and its dataSource
(controller, fetching data from the model to pass to the view) are a
prime example of this.
Ken pointed you to the documentation on MVC - this is really key to
getting this working elegantly. If you can expunge all code to do
with drawing or positioning items from your Data Model, and turn it
into a black box, you'll be well on the way to MVC nirvana ;-)
Thanks again to all
_______________________________________________
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