Cytoscape WikiMikeSmoot - Does this proposal replace the previous Grouping API? Am I correct in thinking that this API implies that we can remove the concept of metanode from GINY? Some specific comments/questions about the API:
- How are createMetaNode/removeMetaNode different than collapseMetaNode/expandMetaNode? Isn't creation of a metaNode implicit in collapseMetaNode? Is there ever a time when you would want to create a metaNode, but not collapse it?
All ArrayList arguments should be Lists instead.
The layoutNodesInAStack method seems out of place. It deals with visualization/layout while the rest of the class deals with the data model. If anything, I would expect the method to be just layoutMetaNodes(CyNetworkView,Nodes,LayoutAlgorithm) and how the nodes were laid out could be decided by the algorithm.
IlianaAvila 4-3-06:
Cytoscape will still need an interface to manage the data structure that will store grouping information (we have not decided on this data structure yet, but you have suggested to use the same one that CyAttributes uses). We could use elements in the old Grouping API, or we could create a brand new one.
- The new API proposed here does imply that the metanode concept can be removed from GINY in the future.
- The reasons why I have create/remove and collapse/expand methods are:
- Performance. It is expensive to permanently remove a metanode each time it is expanded, and create a new one each time it is collapsed (you have to create the metanode, create the edges that connect to it, copy node and edge attributes to the metanode and its edges, do a graph redraw that applies vizmaps, etc)
- Most importantly, there are cases in which you want a metanode to exist in the model, even if it is not collapsed. For example, when you have a metanode hierarchy (where metanodes have metanodes within) and you want to move up and down that hierarchy, either because you are exploring the network as a user, or because you are running an algorithm on the hierarchy
Thanks for the suggestion to use List instead of ArrayList, I'll change this.
- Yeah, the layout method is out of place (I even pointed it out in my code). I will think of a better place for it.
ScooterMorris 4-5-06: This looks like a nice clean interface. I have a couple of convenience functions that I think would help.
The ability to determine if a node is a metaNode would be really helpful. Perhaps something like boolean isMetaNode(CyNode node)? I know that I can determine that by checking for a "nodeType" attribute, but this would provide a very nice shortcut.
- There are a couple of emergent properties that should be available both as attributes on the metaNode and programatically:
- nChildren: the number of direct children of this metaNode
- nDescendents: the total number of descendents of this metaNode
If nChildren == nDescendents then this is a single layer hierarchy (which means that certain optimizations might apply).