Hi Doru, 

Thank you for the explanation.

On Jun 19, 2011, at 10:32 , Tudor Girba wrote:

Hi,

Thanks for the discussion, and sorry for the too long mail, but I did not know how to make it shorter.

Just for reference, there are three basic methods to construct graph elements in Mondrian:
- nodes:using:
- nodes:using:forEach:
- edges:from:to:using:

(And then there is the layout specification: layout:)

These methods offer the means to construct a graph based on your model. They do that through transformations that take entities from your model and produce graph elements. The entities are always passed through the first argument. This is all you should remember.

These methods are like primitives. It might be that your requirements are a level higher and that you need more succinct methods, but these are the basics. All the other rendering methods in ViewRenderer are expressed in terms of these.

Actually, you might notice that you are basically not using any of these methods directly, but through some shortcut methods. However, the idea is that once you understand these methods you should be able to understand the other ones (like edgesFrom:to:)

Ok, I understand.
Now, we should explain it better to redirect new users on the right methods. Maybe, we should put these methods on a protocol named "primitive".



On 19 Jun 2011, at 09:10, jannik.laval wrote:

Hi all,

Doru, I will just explain the context :)
- we have a new big case study on a java source code. We need to build demonstration on-the-fly to show that: (i) our api is simple and efficient, and (ii) everybody can use it.
- I did not build any visualization since 5 months, since I begin to write my thesis, and other papers.
So, when we would like to use Mondrian, the message edges:from:to: is a real problem. It is not the only one, but it illustrates well the problem.
For me, edges:from:to: should be used like "edges: aCollectionOfAssociation from: #first to:#second".

You say it "should be used". But, why should it be used like that when the method is not that? Is it because this is what you think when you look at the name of the method. Or is it because this is what you would like to have as a simple mapping?

I know that the method is not that. But when I see the signature, this is what I imagine. And maybe another name can help to understand it.


I am asking because this is not what the method says. It says "edges: aCollection from: aFromBlock to: aToBlock". The method wants you to provide entities that will be behind the edges. And the other two parameters are transformation blocks, not simple symbols.

It is clear that this is a complex operator. But, giving it another name won't make it easier to understand because the main problem comes from the complexity of the operations. You will inevitably have to learn what those are. And once you do know what they are, the logic becomes evident (at least from my experience).

It's like #do: in Smalltalk. This is highly cryptic for non-Smalltalkers mainly because they do not know what a block is. But, once you understand what a block is, it becomes clear and elegant. It's the same here.


To give a collection of nodes is not intuitive for 2 reasons:
- the first one is in my example: I always think to provide edges and not nodes.

You do not provide edges, or nodes. You provide entities. I believe this is the root of the problem. You are looking at it from the other perspective, which might be valid, but it is not what Mondrian does.

The key is to remember that Mondrian is a transformation engine and that it works with models that do not have nodes and edges, but only entities. You map them on nodes and edges. Perhaps this is what needs to be documented.

yes, I understand that.
I know that we manipulate entities. but each node has an entity behind. And behind edges there are association of entities.
What is strange for me is to provide a collection of entities that should be connected with edges, whereas they are provided before in the script.

Ok, I am understanding that I should not see this method in the process but as a generic method :)



- the second is: why to give nodes ? we should have them because we are building a node-visualization. So the selection of good nodes should be done in the blocks from:to:.
In fact, I think that a first thing to do is to use the methods edgesFrom:to: (that I just discover...)

This is a shortcut - see above. There are several such shortcuts in ViewRenderer. Maybe they need to be better documented.


Yes, we should do that.


Another problem that I encounter with Glamour also, is the debugging. And I really think that problems  could be resolved with a good integration with the debugger. For now, it is not possible to understand easily why a script does not run as we want.
We should think how to integrate the debugger in Mondrian and Glamour scripting.

Exactly, this is the key next step!

Cool :)))



The discussion is open :)

Thanks :).

Thank you for your explanations, again :)
Jannik



Cheers,
Doru


Jannik

On Jun 18, 2011, at 19:03 , Tudor Girba wrote:

Hi,

On 18 Jun 2011, at 18:36, Stéphane Ducasse wrote:


Something that tells me how to pass the correct arguments and edges: does not work because these are not the edges that you pass.

buildEdgesFrom: aCollection usingFrom: usingTo:
would be something in the right direction.

I suggest an even better approach:

buildEdgesFromACollectionWithEntities:
usingATransformationBlockAppliedOnEachToGetTheOrigin:
andUsingATransformationBlockAppliedOnEachToGetTheTarget:



_______________________________________________
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