Design in Mondrian

Hi!

One strong principle in Mondrian is to have graph elements independent of their representation. A graph element being just a wrapper of the domain object. This is what has been enforced in the VW and Pharo versions.

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?

Currently, we have the following responsibilities:
a graph element:
  - keeping a ref to its shape
  - managing caches
  - managing attributes
  - managing nesting of nodes and edges
  - layout
  - supporting announcement

a node:
  - keeping a location
  - maintaining a zordered-list of elements to display
  - dedicated caches (e.g., bitmap)
  - rendering on a canvas

an edge:
  - target and source node
  - rendering on a canvas

a root:
  - selection box
  - another event management

Clearly, some responsibilities are ill located. I will do soon some cleaning...

Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.





_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Hi Alex,

> One strong principle in Mondrian is to have graph elements independent of their representation. A graph element being just a wrapper of the domain object. This is what has been enforced in the VW and Pharo versions.
>
> 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.

> Currently, we have the following responsibilities:
> a graph element:
>  - keeping a ref to its shape

This is not a responsibility, it's a collaboration

>  - managing caches

This is internal implementation. This could probably be moved indeed.

>  - managing attributes
>  - managing nesting of nodes and edges
>  - layout

It is responsible for the positioning, but this is achieved through a collaboration

>  - supporting announcement

This is again a collaboration, because the interaction responsibility is handled by the announcer.

> 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.

>  - rendering on a canvas

Not quite correct. The actual rendering is taken care of by the shape.

> an edge:
>  - target and source node
>  - rendering on a canvas

Not quite correct. The actual rendering is taken care of by the shape.

> a root:
>  - selection box

I think this could go to the Canvas.

>  - another event management

I am not sure what this is.

> 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.

Cheers,
Doru



--
www.tudorgirba.com

"Some battles are better lost than fought."




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

>> 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?

>
>> 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.

>> - 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.

>> - 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

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.





_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

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 :)

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.

The location is the job of the node :). The caching structure might be somewhere else, though.

Cheers,
Doru


--
www.tudorgirba.com

"To lead is not to demand things, it is to make them happen."




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

> 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.

But the question is whether having GraphElement>>bounds make more sense than MOShape>>boundsFor:

> 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 :)

I am just looking for ways to simplify Mondrian. The VW version of Mondrian was complex. We have simplified it over the years. But it remains complex.

Cheers,
Alexandre

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.





_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Hi,

On 3 Apr 2011, at 13:55, Alexandre Bergel wrote:

>> 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.
>
> But the question is whether having GraphElement>>bounds make more sense than MOShape>>boundsFor:

I do not understand. The Element (I really would call it Figure because it would convey much better the intention) that has to retain the instance variable. The logic that depends on the model is in the shape. In the case of bounds it delegates to Shape>>computeBoundsFor:

>> 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 :)
>
> I am just looking for ways to simplify Mondrian. The VW version of Mondrian was complex. We have simplified it over the years. But it remains complex.

It is great to want to simplify a design, but this would only happen if you introduce some extra concepts (like a Graph). However, this comes at a price, but maybe it is worth it.

Regarding VW vs Pharo, I do not see where the Pharo version is less complex than the VW version. In fact, with the caching it is slightly more complex.

Cheers,
Doru

--
www.tudorgirba.com

"One cannot do more than one can do."




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

>>> 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 :)
>>
>> I am just looking for ways to simplify Mondrian. The VW version of Mondrian was complex. We have simplified it over the years. But it remains complex.
>
> It is great to want to simplify a design, but this would only happen if you introduce some extra concepts (like a Graph). However, this comes at a price, but maybe it is worth it.

Not only. For example, I am not convinced about the class MOBrowser. Maybe the Easel should be an independent project on which Mondrian would depend on.

> Regarding VW vs Pharo, I do not see where the Pharo version is less complex than the VW version. In fact, with the caching it is slightly more complex.

When I said, I was referring to small things, such as having shorted methods and smaller classes.
A few months I made the core of mondrian completely independent from other packages.

Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.





_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev