19 Jun
2011
19 Jun
'11
2:09 p.m.
Hi Doru,
Thank you for the explanation.
On Jun 19, 2011, at 10:32 , Tudor Girba wrote:
Yes, we should do that.
Cool :)))
Thank you for your explanations, again :)
Jannik
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:
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.
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 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.
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 :)
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. - 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.
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! The discussion is open :)
Thanks :).
Cheers,
Doru
Jannik
On Jun 18, 2011, at 19:03 , Tudor Girba wrote:
--
www.tudorgirba.com
"Some battles are better lost than fought."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev