Diff for "API/NewApiApproachForMetaNodes/CommentNewMetaNodeApi"

MikeSmoot - 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).

• Also, it would be really useful to have an additional "createMetaNode" method (or convertToMetaNode?) that takes an existing CyNode and a subnetwork and converts that CyNode into a metanode. This would be particularly useful for routines that read and write various hierarchical information (think XGMML). Currently, you read the node with all of the information and its children - then turn all of the children into a metaNode (which returns a new CyNode), which you then need to reassign the attribute information to. This could be done depth-first, but that might complicate the code depending on the actual grammar.

ScooterMorris 4-7-06: I really like the new methods you added to the API! I can immediately see how I could use them to add functionality to the UI (like open this metanode in a new view). Excellent! Once we have the XGMML reader/writer stuff worked out, this is going to be very useful.

GaryBader - Apr.14.2006 Looks great Iliana - I had some questions: * Will multiple views be supported in the future? If so, this should be added to the MetaNodeUtils class comment, where it discusses that the view and model are currently sync'ed * For the create_multiple_edges parameter, is this operation completely reversible? If false, is an attribute for the number of edges collapsed created? This would be useful for the visual style to map the number of edges to line width. * What happens if a metanode is added as a child of itself - is an exception thrown? * Would getBottomLevelChildren -> getLeaves and getTopLevelParents -> getRoots be simpler? * Have we chosen a consistent naming scheme for create/remove (delete/destroy/hide, etc.) concepts in Cytoscape? If we have, this API should use the same names.