Re: MVC question
Re: MVC question
- Subject: Re: MVC question
- From: Ryan Bates <email@hidden>
- Date: Tue, 10 Feb 2004 09:55:01 -0800
On Feb 9, 2004, at 6:04 PM, Koen van der Drift wrote:
The information about the new node and location is then passed to the
controller and model, which then creates the new node in the correct
position (in the graph I mean, not the view). [...] And where do I
store the coordinates of each node?
It sounds like you have the right idea. The graph should have its own
coordinates system completely separate from the view. Each Node object
could store its position in the graph (not the view). This makes sense
because it is part of the "information" so it should be stored in the
model.
I don't know the best way to store the node connections, but they
should be in a model object. One way is to have each Node store a
pointer to the Nodes it is connected to. Another possibility is to
create a NodeConnection class that contains a pointer to two Nodes that
need to be connected.
If you haven't done so already, there could be an AcyclicGraph type
class (separate from the view) that stores an array of Nodes. It could
also contain an array of NodeConnections if you have them. I think that
would make the most sense.
As far as the drawing goes, I would create an AcyclicGraphGraphic class
(okay, you might want to pick a different name) that contains an
instance to the AcyclicGraph to be drawn. This graphic could have a
draw method which draws all of the nodes and connections in the graph
at a certain scale, position, rotation, etc. This would actually be a
view class rather than a model, however, it probably will not subclass
NSView. It would be similar to one of the Sketch graphic classes.
Now how does the information of the new node get to the view? Is it ok
to pass a pointer from the model to the view?
I think the main NSView subclass should have an AcyclicGraphGraphic
instance variable. In the "drawRect:" method you could call the
AcyclicGraphGraphic's "draw" method after the position, scale, etc. has
been established. This way, when anything changes in the graph, all you
have to do is tell the view to redraw itself. You could communicate
this through an NSNotification or through a controller class.
Are there any Cocoa examples of apps that draw a (directed acyclic)
graph?
I don't know of any, but Sketch is a nice example for anything that
does drawing. If you haven't, you may want to check Apple's example
Cocoa source code:
<
http://developer.apple.com/samplecode/Sample_Code/Cocoa.htm>
I hope this is all makes sense.
Ryan
On Feb 9, 2004, at 6:04 PM, Koen van der Drift wrote:
On Feb 8, 2004, at 4:18 PM, Ryan Bates wrote:
Let's say you are drawing a clock. You could create a Clock model
class that keeps track of time. You could then create a ClockGraphic
class that draws a Clock object. You could even go a step further and
create an AnalogClockGraphic and a DigitalClockGraphic to draw the
same Clock two different ways.
In my case what's drawn is a directed acyclic graph. Now lets say the
user adds a new node by editing the view, eg by dropping a node from a
palette between two other nodes. The information about the new node
and location is then passed to the controller and model, which then
creates the new node in the correct position (in the graph I mean, not
the view). Then the controller gets notified that the model has
changed, and tells the view to draw the new node where it was dropped
and to which other node it needs to be connected. Now how does the
information of the new node get to the view? Is it ok to pass a
pointer from the model to the view? And where do I store the
coordinates of each node? Especially this last point is what puzzles
me.
Are there any Cocoa examples of apps that draw a (directed acyclic)
graph?
An additional question, since I am rewriting the app from scratch,
would this type of app benefit from using Cocoa bindings?
I really don't know much about bindings, but it seems to be best
suited for widget-type applications. Throw bindings in with a couple
buttons and a table view and you can create a simple program with
almost no code, but when it comes to a drawing application where most
of the GUI is made up of custom objects, it might be harder to
implement bindings. I could be wrong though.
I have some textfields that need to be updated when the graph changes,
so I guess bindings can be useful there.
thanks,
- Koen.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.