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
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 shapeIn 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:
- Roassal appears to not provide any methods that have "using:" in them.
- 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
<MOFormsBuilder.png>_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Some battles are better lost than fought."
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@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 shapeIn 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:
- Roassal appears to not provide any methods that have "using:" in them.
- 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
<MOFormsBuilder.png>_______________________________________________ Moose-dev mailing list
Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Some battles are better lost than fought."
Moose-dev mailing list
Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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@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 shapeIn 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:
- Roassal appears to not provide any methods that have "using:" in them.
- 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
Having a way to offset shapes is indeed important. A kind of wrapper for shapes using a decorator.
Alexandre
On Aug 3, 2012, at 1:25 PM, Ben Coman btc@openInWorld.com wrote:
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@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 shapeIn 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:
- Roassal appears to not provide any methods that have "using:" in them.
- 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
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Alexandre Bergel -
Ben Coman -
Tudor Girba