Just some additional musings... looking below at my last post where both
ROBox & ROBorder are added to a node, it seems that a node can hold
multiple shapes even if they aren't "composed." Perhaps one simpler
option that might satisfy my need would perhaps be having a
ROOffsetLabel - having a relative offset from its usual location. This
would have a callback onto the model so that several different texts
could be associated with a node and dragged around with it.
An alternative might be to consider a implementing a common interactive
feature of drawing packages where multiple nodes can be selected and
"grouped" into one node which are moved around together. This might be
a desirable feature overall and also be used to composing complex shapes.
I guess another alternative would be for myself to create my own
subclass of ROShape.
Now there is a second thing to consider from my example below. My
#mondrianShape methods were implemented as a method within of the model
- which I think is poor OO design - but at least got something working
quickly. I think perhaps now ROShape is av- however I require the
selected shape to follow the inheritance structure of the model - by way
of example perhaps anything subclassing from MyModelContainer would have
one shape and anything subclassing from MyModelSwitch would have another
shape.
What I propose then is a node having a definable callback on the model
that returns the "Class" of required shape. This callback selector
might be stored within the node, or might be a supposed shape
DynamicProxyShape - which continually asks for the shape from the model,
and then draws that shape. With the model returning the "Class" of a
particular shape, then the coupling is that the model knows "which
shape" it wants drawn, but not "how" to draw it, which defined
as-a-kind-of-ROShape. I am not sure how that aligns with good OO design
or not.
cheers, Ben
Alexandre Bergel wrote:
As Doru said, Roassal does not provide a way to
compose shapes. I will work on it soon, but right now you can't compose. One easy way
to render something that looks like what you have shown is to nest nodes:
view node: 'UML' forIt: [
view shape rectangle withText.
view node: 'ROShape'.
view shape label text: [:el | el model selector].
view nodes: ROShape methods.
view verticalLineLayout
].
Soon we will have more...
Cheers,
Alexandre
On Jul 29, 2012, at 10:48 AM, Ben Coman <btc(a)openInWorld.com> wrote:
> Okay. What is the next best approach for what is available at the moment? Subclass
one of the other ROShapes... ?
>
> I noticed "ROElement>>addShape: " What is the philosophy/architecture
there?
> Reviewing all the senders shows that 90% only call #addShape: once. The only case
where #addShape: is called multiple times on an object it always looks like this...
> node
> addShape: ROBox new;
> addShape: ROBorder new.
>
> cheers, -ben
>
> Tudor Girba wrote:
>
>> Currently, there is no support for complex shapes. This is definitely a direction
in which we have to invest.
>>
>> Cheers,
>> Doru
>>
>>
>> On 28 Jul 2012, at 18:06, Ben Coman wrote:
>>
>>
>>
>>
>>> Referring to the attached graph, what is the best way to approach the
following in Roassal.
>>> Currently with Mondrian I produce a produce a custom shape using the forms
builder in #mondrianShape, which is a method of my ModelRoot class. Referring to the
attached graph, as an example this shows the class name "Substation" above the
instance "SS1" and has a space for contained items to be displayed within it.
>>>
>>>
>>>
>>>
>>>>> mondrianShape
>>>>>
>>>>>
>>>>>
>>> | builder |
>>> builder := MOFormsBuilder new.
>>> builder column; center; fill; pref; grow.
>>> builder
>>> row; center; pref; fill; grow;
>>> row; center; pref; fill; grow;
>>> row; center; pref; fill; grow.
>>> builder x: 1 y: 1 add: ( MORectangleShape new text: #strippedClassName;
textAlignment: #left; borderColor: Color white ) .
>>> builder x: 1 y: 2 add: ( MORectangleShape new text: #localName;
textAlignment: #left ) .
>>> builder x: 1 y: 3 add: ( MORectangleShape new ) .
>>> builder x: 1 y: 3 add: ( MOChildrenShape new ) .
>>> ^builder shape
>>>
>>> In conjunction with the use of MOChildrenShape above, class ModelRoot also
has method #addSubViewTo: which descends through contained classes - for example instance
"primary" inside "T1" inside "SS2" inside "Figure
8..."
>>>
>>>
>>>
>>>
>>>>> addSubViewTo: aMOViewRenderer
>>>>>
>>>>>
>>>>>
>>> aMOViewRenderer
>>> node: self
>>> using: self mondrianShape
>>> forIt:
>>> [
>>> self children do:
>>> [ :child |
>>> child addSubViewTo: aMOViewRenderer.
>>> ]
>>> ]
>>>
>>> My initial issues in migrating this to Roassal are:
>>> 1. Roassal appears to not provide any methods that have "using:" in
them.
>>> 2. Roassal appears to not support MOFormsBuilder
>>>
>>> It may be that I am accessing to much internal methods. The code above was
the result of evolutionary hacking as I was learning Mondrian. I would be happy to
re-architect if someone can advise best practice for Roassal.
>>>
>>> cheers -ben
>>>
>>>