It seems I managed again to sound like scolding :).
- do you still need the new method given that you have one that does
that already and that by adding the new one we break the conventions
for what it means to not pass a model to an edge?
Hard to say right now. Probably not, but I will check with the example
of Jannik
- regarding the limitations you mentioned, is the example below
enough, or are there more limitations you see? Or did I
misunderstood completely?
On 25 Mar 2009, at 10:44, Alexandre Bergel wrote:
> I did not suggest that we should change the convention name. There
> is enough documentation around to make us stick to it. I will
> rename the method I recently introduced.
>
> Cheers,
> Alexandre
>
>
> On 24 Mar 2009, at 21:48, Tudor Girba wrote:
>
>> 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
>>
>> --
>>
www.tudorgirba.com
>>
>> "To lead is not to demand things, it is to make them happen."
>>
>>
>>
>> _______________________________________________
>> 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
"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