This may be possible in the current version, but the solution did not seem obvious to us. If you have suggestions on what approach you would use that would be great.
We want to have a control that acts like a swim lane you might see in some commerical process editors. The swim lane would act alot like a subgraph except its boarders would not size according to contents, and there would be an addional “header”. Horizontal and Vertical swim lanes would be nice, and the ability to limit the type of links you could cross swim lanes with, and limits you can place on the types of nodes that could be placed in each swim lane.
I know customers have been implementing swim lanes, with varying features, for many years. Some just want swim lanes as background objects, really just decoration. Others want them to be containers, as it seems you want.
You can easily define your own JGoArea subclass that has the appearances that you want. Presumably the layoutChildren method would position the “header” relative to the JGoRectangle that represents the lane. Maybe it’s resizable. You would make sure the nodes that belong in the swimlane are added as child objects.
You can override JGoView.validLink or JGoPort.validLink to check what nodes and/or swimlanes might be connected.
You can override JGoView.computeAcceptableDrop to determine if you want to allow a drop to occur at a particular point–you’ll need to see if the point is in one of the permissible swimlanes.
One more question on the same topic. Lets say we have multiple nodes with in a given subgraph ( swim lane) and we want to detect when we “jump” lanes ( ie move either between swim lanes or connect to objects that are not part of a given subgraph). In our project we want to “group” nodes (which are workflow tasks) together to denote a transaction set. We want to do the equivilant of a commit or roll back when a link if followed that connects to a node outside of the subgraph. What is the easiest way to detect, the fact that we have “moved” outside our current JGoArea?
OK, lets call “SwimLane” the JGoArea subclass that implements swim lanes.
Are you asking how does one statically analyze a JGoDocument to see if there are links between SwimLanes? You can just iterate over all of the JGoLinks and see if their ends are connected to ports that indirectly belong to different SwimLane objects, perhaps by calling JGoObject.getTopLevelObject().
Or if you want to dynamically limit what links users can draw (or reconnect), you can override JGoView.validLink or JGoPort.validLink to do the same check.
Regarding moving nodes: as long as a JGoObject is part of a JGoArea, that parent area’s bounding rectangle is defined to include that child JGoObject. So there isn’t any easy way for a user to drag one of your nodes out of the SwimLane that it is part of.
However, if you are using this kind of container approach to swim lanes, I assume you will have a JGoRectangle (or maybe a JGoArea holding a JGoRectangle and other decorations) that provides the visual appearance of a “lane”. Let’s call that class “Lane”. Its class would not inherit from JGoNode. This would be the first child object of the swim lane, at the head of the list, so that the lane will be drawn underneath/before the nodes that are part of the swim lane. Perhaps users will be able to resize this rectangle/“lane” object.
Anyway, having a separate rectangle as the Lane means that the nodes that are part of the SwimLane can easily be positioned outside of the rectangle. After any move (JGoViewEvent.SELECTION_MOVED) you can see if each node that was moved is no longer in its SwimLane’s Lane. You’ll need to decide what to do about partial overlaps. And of course you’ll need to decide what to do when a node is now over a different SwimLane’s Lane. I’d recommend calling JGoArea.addChildren to reparent the node to the new SwimLane, so that users won’t get confused about which nodes belong to which SwimLanes. But you’ll also need to figure out what to do about nodes that are dragged outside of any Lane.
I am also interested in this swimlane implementation. I appreciate very much if you could suggest how to use AutolayerLayout to do the layout vertically within the lane and horizontally cross lanes
Assuming SwimLanes did NOT own nodes and links, I would just do the autolayout and then figure out exactly how deep each layer is and construct the appropriate background SwimLane objects of the corresponding depth, with enough breadth to cover the whole graph.
In other words, pretend there are no swimlanes at all, and do the autolayout. Then construct the swimlanes and add them to a background document-layer, with bounds that are wide enough to extend across the whole graph and with height that is big enough to encompass the layered-digraph layers.
Your suggestion seems to be appropriate for constructing swim lanes after the network got constructed. What if there are a fix number of swim lanes that are always there on the background and the whole view is alway corvered by the lanes despite of zooming, rescaling, resizing.
Appreciate your suggestions