Alexandre,

As a broader scenario from that specific MNU, what I can provide is a snapshot of my project. It is the same one I showed you a few months ago, but converted from the original Mondrian to use the lower-level API of Roassal. In the attached screen shot you can see nested ROEements, each labeled as: ModelClassname "instance identifier". The green-circles are instances of ConnectivityNode and the black-circles are instances of Terminal. ConnectivityNode is a container that holds terminals, as shown by the edges between them. Just for background info, also attached is a cutout from the IEC61970 UML diagram showing relationship of Terminals to ConnectivityNode.

So what I need is to be able to draw edges _only_ from Terminals to ConnectivityNodes (and "maybe" the reverse direction as well). The models of the ROElements come from many different classes, and any conditional block to evaluate acceptance of a drop needs to take account of accessors being different between each class. How is the best way for the Roassal architecture to provide this functionality?

It might be useful (for me :) ) if you could download and have a look at the running project. Browse to "http://files.openinworld.com/ENG8002" and then if you happen to have 7zip on you system, download "20120922-moose47-LEETRICAL.7z" at 19MB or otherwise download "20120922- moose47-LEETRICAL.zip" at 29MB. Vanessa might also like a look.

cheers -ben

Alexandre Bergel wrote:

Hi Ben,

I think that the best to describe your situation is to provide a test that raise this MNU.
The test should use the scenario you would like to see working.
This will help us get our effort focused. 

Cheers,
Alexandre


On Oct 18, 2012, at 10:58 PM, Ben Coman <btc@openInWorld.com> wrote:

With the recent integration of RORubberBand, I have then gone to use it in my application. What arises is that while the implementation works well within a single script in ROExample, it is not so well when the creation of elements is more spread out in different parts of the code, since these different parts do not have access to the same instance of RORubberBand. So some further thoughts on rubberbanding for discussion...

1. Since the rubberband operation is between elements, perhaps this should not be stored inside individual ROElements but more globally in ROView. That is, perhaps ROView would have its own interactions.

2. Currently to avoid the MNUs due to the target filter condition processing edges and elements with nil or unsuitable model, in (RORubebrBand>>initializeElement:) I used (candidateTarget getInteraction: self ifPresent:) where it is the 'self' that ensures that source/target elements being compared are applicable to a particular RORubberband. It is that 'self' that is hard to distribute to elements that are created from different parts of the code. Perhaps this mechanism could be replaced by tagging RORubberBand defined in different elements with a common symbol eg #rubberband1

Or tag the elements associated with a particular rubberbanding are just tagged the same as the RORubberBand instance stored in the ROView.

3. Perhaps not bother with trying to ensure no exceptions occur in the execution of the target filter condition, and just mask them out. Rather than interrupting the program with a MNU, targets elements are simply excluded if the filter.

What are your thoughts?

cheers -ben
<RoassalMethodComparison.xls>_______________________________________________
Moose-dev mailing list
Moose-dev@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev