elk
elk copied to clipboard
Allow layout connectors to trigger multiple layout runs
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.
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.
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.
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.
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?
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.
Aah, then adding a parameters property to LayoutMapping might be the easiest and most convenient solution.