elk icon indicating copy to clipboard operation
elk copied to clipboard

Allow layout connectors to trigger multiple layout runs

Open le-cds opened this issue 8 years ago • 6 comments

There seems to be a problem with the way multiple layout runs are triggered. The easiest way to do so is to invoke one of the DiagramLayoutEngines invokeLayout(...) methods and passing it a Parameters object with multiple layout runs. However, when those parameters are configured, there is no layout graph yet. This might not be the best place to actually configure the layout runs. In fact, the best place would probably be the layout connector.

I propose to add a method getLayoutParameters() to the IDiagramLayoutConnector interface. Those, if non-null, would be used as the basis for the layout runs. If parameters are passed to invokeLayout(...), those could serve to override the parameters built by the layout connector.

le-cds avatar Jan 07 '17 13:01 le-cds

Another possible solution: extend LayoutConfigurator so it can assign properties to elements with a given identifier, maybe even with qualified syntax like in the new textual format, e.g. node2.port1. Then you need to make sure the layout connector generates proper ids for all elements. We could add ids to the default GMF and Graphiti connectors.

spoenemann avatar Jan 09 '17 10:01 spoenemann

In addition to the identifier-based referencing of elements, we could add an interface IParametersProvider that is injected with @Inject(optional=true) in DiagramLayoutEngine. If an implementation is present, the parameters returned by it would be merged with those of the actual call. I would prefer this over extending IDiagramLayoutConnector with another method.

spoenemann avatar Jan 09 '17 10:01 spoenemann

I'm not sure how the first proposal would solve the problem. The latter proposal, however, seems sensible to me. An IParametersProvider would be called after the layout connector has built the layout graph and thus would have an idea of how exactly to configure different layout runs.

I propose however to not implement this for 0.2.0 anymore.

le-cds avatar Jan 09 '17 12:01 le-cds

I'm not sure how the first proposal would solve the problem.

That depends on the use case. What is the use case that drove this issue?

spoenemann avatar Jan 09 '17 13:01 spoenemann

The user tried building a Parameters object inside the DiagramLayoutEngine since he couldn't figure out where to cobble that together. It then dawned on me that the place to configure layout should be their IDiagramLayoutConnector implementation, since that is where the code has knowledge about which graph object represents which view model object and how to configure layout accordingly. But the layout connector provides no way to configure multiple layout runs. Thus, the next viable solution would be to call DiagramLayoutEngine directly with an appropriate Parameters object. That solution, however, quickly breaks down as the layout configuration needs to become more complex since at that point the layout graph has not been built yet.

All in all, that's why I suggested somehow allowing IDiagramLayoutConnector to build up multiple layout configurators as it creates the layout graph, perhaps saving those in the LayoutMapping.

le-cds avatar Jan 09 '17 13:01 le-cds

Aah, then adding a parameters property to LayoutMapping might be the easiest and most convenient solution.

spoenemann avatar Jan 09 '17 14:01 spoenemann