Community
Participate
Working Groups
Build Identifier: We used Zest 1.1 to create specific layouts we called domain-specific layouts, that read during layouting model informations, and adjusts the final layouts to incorporate changes. For this reason we used the following code: InternalNode sn = entitiesToLayout[x]; GraphNode node = (GraphNode)sn.getLayoutEntity().getGraphData(); Since Zest 2.0 this is not possible any more, as EntityLayout does not provide any option to reach the GraphNode object. The class InternalNodeLayout has a getNode() method, that provides such a functionality, however, both the class and the method are protected (default visibility), so this cannot be called outside. I would like to either extend the visibility of this getNode() - probably add it to the EntityLayout interface, but that is not required for us, or provide a different way for reaching these elements, as they would be helpful. Thanks for your help. Reproducible: Always
Having a way to get the items that are being laid out would be useful indeed. To me it seems adding it to EntityLayout isn't ideal though, since that is also extended by SubgraphLayout for which such a method doesn't seem to make sense. Perhaps we could add a method only to NodeLayout which returns the node as an item - we could then access them from the layout context something like this: Item node1 = context.getNodes()[0].getItem(); // a GraphNode It would also allow access to node items in subgraphs: Item node2 = context.getSubgraphs()[0].getNodes()[0].getItem(); Could this be a sensible approach? Would it work for you?
That seems exactly what I want, thanks. Maybe a common interface can be reached by adding a getAllNodes() method, that return an array of Items, that can contain all nodes in the subgraphs recursively. If you think, it would work as expected, then I will provide a patch solving it that way.
Yes, that sounds like a nice way to do it. To avoid confusion in classes implementing SubgraphLayout (which defines the getNodes method that returns a NodeLayout[]), and since the new method would return an Item[], perhaps we should call it getItems?
Created attachment 189380 [details] A proposed patch Added a patch that creates the corresponding methods. As the EntityLayout interface does not reach GraphItem/GraphNode classes, the new method returns Object[]
Thanks - applied your patch, changing the return type to Item[] (the most specific we can get in the layouts bundle), and adding some tests (see LayoutAlgorithmTests).
