Hi Alex,
I am not sure I understand where the limitation is. It's just a naming
convention to describe the view, rather than to add things to it. I
see no reason to start changing it now.
You can have as many "view nodes: " and "view edges:" you want. For
example, the following code, works just fine in Squeak:
view := MOViewRenderer new.
view shape: (MORectangleShape new ).
view nodes: #(1 2 3 4).
view edgeShape: (MOStraightLineShape new).
view edges: #(1 2 3 4) from: #yourself to: [:x | x + 1].
view shape: (MORectangleShape new fillColor: Color red).
view nodes: #(5 6 7 8).
view edgeShape: (MOStraightLineShape new color: Color red).
view edges: #(5 6 7 8) from: #yourself to: [:x | x + 1].
view treeLayout.
view open
For your case of the layout, you actually want to tell the layout to
only take into account the inheritance edges. The solution in is to
pass userDefinedEdges: to the layout with the edges returned by the
view edges:. For example in the following code I store the second set
of edges in an "active" variable and then pass it to the layout:
view := MOViewRenderer new.
view shape: (MORectangleShape new ).
view nodes: #(1 2 3 4).
view edgeShape: (MOStraightLineShape new).
view edges: #(1 2 3 4) from: #yourself to: [:x | x + 1].
view shape: (MORectangleShape new fillColor: Color red).
view nodes: #(5 6 7 8).
view edgeShape: (MOStraightLineShape new color: Color red).
active := view edges: #(5 6 7 8) from: #yourself to: [:x | x + 1].
view treeLayout userDefinedEdges: active.
view open
Cheers,
Doru
On 24 Mar 2009, at 17:47, Alexandre Bergel wrote:
I see your point.
However, I am wondering about limitation of this declarative way of
defining nodes and edges. Beside the fact that I had troubles to
understand what's really going on when I write "view nodes: ..." and
especially "view edges: ...", this syntax misses the inherent
imperative way of defining a view with several kinds of nodes and
edges. For example, to me, it looks perfectly reasonable to have
-=-=-=-=-=-=-=-=-=-=-=-=
view shape: shape1.
view nodes: (1 to: 99).
view shape: shape2.
view nodes: (100 to 199).
-=-=-=-=-=-=-=-=-=-=-=-=
The example is contrived, but it reflect some situation where I need
more than one "nodes:" or "edges:" at the same level. A more
realistic example may be found in UML, where edges used for simple
associations between classes are different from inheritance edges.
I will typically add the simple association edges after having done
the layout.
I always though that having "addNodes:" and "addEdges:" is more
explicit. It seems that Lukas came to the same conclusion (he used
"addAll:"). But I might be wrong...
Cheers,
Alexandre
On 24 Mar 2009, at 17:19, Tudor Girba wrote:
But, why would you add another method for this?
Also, please do not add verbs in the API, like (add*). For example,
it is edge:from:to:, and not addEdgeFrom:to:.
You might want to name it edgeFrom:to:, but that does not work
because the assumption when we do not give the model is to take the
collection of the objects behind the nodes.
Like this you can write:
view nodes: classes.
view edgesFrom: #superclass.
This case is much more often encountered then having an edge
without a model at all.
So, all in all, I would not add this new method.
Cheers,
Doru
On 24 Mar 2009, at 16:54, Alexandre Bergel wrote:
I did not see this...
It will make addEdgeFrom:to: shorter then.
Thanks,
Alexandre
On 24 Mar 2009, at 16:50, Tudor Girba wrote:
Hi Alex,
There is no need for that because you already have support for
that:
view := MOViewRenderer new.
view nodes: #(1 2).
view edge: nil from: 1 to: 2.
view open
This is because:
Object>>moValue: anArgument
^ self
Cheers,
Doru
On 24 Mar 2009, at 16:44, Alexandre Bergel wrote:
> Hi All,
>
> Several time I saw the need to add a particular edge between two
> nodes that I know. I added a new method addEdgeFrom:to: in
> ViewRenderer.
> Here the appropriate test. Feel free to comment.
> -=-=-=-=-=-=-=-=-=-=-=-=
> testAddEdge
> | view |
> view := MOViewRenderer new.
>
> view nodes: (1 to: 2).
> view addEdgeFrom: 1 to: 2.
>
> window := view open.
> self assert: (view root edges size = 1).
> self assert: (view root edges first source =
> (view nodeForDomainValue: 1)).
> self assert: (view root edges first target =
> (view nodeForDomainValue: 2)).
> -=-=-=-=-=-=-=-=-=-=-=-=
>
> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel
http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel
http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of
problem understanding."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel
http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev