Hi,
On 2 Apr 2011, at 20:33, Alexandre Bergel wrote:
However, this has not been completely nice and clean. For example, MOGraphElement defines #bounds, #absoluteBounds. MONode defines #translatedBy:. Shall these methods be moved into the shape?
I disagree that this is a problem. The Element has a physical location and dimension, the Shape is responsible for retrieving the actual values from the model.
bounds is about the size of the shape. Is it reasonable to have a graph element answering to the message #bounds?
Yes. Bounds is about the bounds of the figure. A Shape object is a strategy and it is shared among multiple elements. Thus, it cannot hold data specific to one element.
I believe the below issues really stem from what we understand by Element.
As I said, in the very original version of Mondrian, we had Figure and Graph separately. The Figure was responsible for the position and size. The Graph was a container. Afterwards, we merged the two structures to have less objects and to have less indirection which kind of made the code harder to follow.
So, Graph was merged in, and in the end we only had Figures. The idea of Mondrian was to focus on the presentation, so Figure is really what it says: a Figure :). And like a figure, it has a position and a size, and it knows how to draw itself on a physical canvas, and how to deal with interaction. That is quite well defined.
Now, you renamed Figure to Element, which as I said from the beginning does not really convey the original idea. And because of this name, now we can start to say that the job of the Figure is not part of the responsibilities of an Element. While this could be a possible direction, it goes away from the original idea.
I am just wary about adding more layers if there aren't strong reasons for it. On the other hand, it can well be that it scales in the end. So, we can experiment but we should be careful to trace the effects :)
Currently, we have the following responsibilities: a graph element:
- keeping a ref to its shape
This is not a responsibility, it's a collaboration
sure
- managing attributes
- managing nesting of nodes and edges
- layout
It is responsible for the positioning, but this is achieved through a collaboration
In addition, the layouting should not be at the level of GraphElement. It does not make sense for an edge to do a layout.
In the original Mondrian, we actually could have graphs in the edges to model fancy annotations on the edge. We had some experiments, but in the end we did not really manage to get the bounds of the subgraph properly.
- supporting announcement
This is again a collaboration, because the interaction responsibility is handled by the announcer.
Sure (bis)
a node:
- keeping a location
- maintaining a zordered-list of elements to display
- dedicated caches (e.g., bitmap)
This is internal implementation, but it could probably be pushed externally somewhere.
Yes. The node location should not be hosted within a node.
The location is the job of the node :). The caching structure might be somewhere else, though.
- rendering on a canvas
Not quite correct. The actual rendering is taken care of by the shape.
MONode and MOEdge define displayOn: A node needs the zordered-list to display its inner nodes. I will move this into a visitor soon.
an edge:
- target and source node
- rendering on a canvas
Not quite correct. The actual rendering is taken care of by the shape.
But it is called by the graph element
a root:
- selection box
I think this could go to the Canvas.
Yes, I agree.
- another event management
I am not sure what this is.
Updating the size of the root if you drag and drop a node. This could go in the Canvas maybe.
Clearly, some responsibilities are ill located. I will do soon some cleaning...
I think there are some places for refactoring, but not that many as it might sound from your mail. One thing that you might need to know is that we used to have an explicit Graph entity. However, we ended up merging it in the Element because of scalability issues (less objects). Perhaps the situation is different now, but we nevertheless should take care of this aspect, too.
As far as I remember, what was called a graph was an instance of the formally named Figure (which was replaced by GraphElement).
Cheers, Alexandre
Cheers, Doru
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Some battles are better lost than fought."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"To lead is not to demand things, it is to make them happen."