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
"To lead is not to demand things, it is to make them happen."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch