Visual Property Discussion

Existing System

Use Cases

• UC1: CyNetworkViewReader constructs CyNetworkView with visual properties from a non-XGMML source.

• UC2: CyNetworkViewWriter writes a non-XGMML CyNetworkView with visual properties to disk.

• UC3: Plugin creates a visual style.

• UC4: Plugin creates a discrete visual mapping.

Issues

1. Visual properties of inaccessible types (e.g. org.cytoscape.ding.NodeShape) are awkward to set programmatically.

   • Currently, you need to use a VisualProperty instance to construct a NodeShape instance by parsing the serialized form of the desired shape.

2. Visual properties of inaccessible types (e.g. org.cytoscape.ding.NodeShape) are awkward to use with discrete mappers programmatically.

3. Not possible to serialize visual properties for formats other than XGMML.

Assumptions

• RenderingEngine implementations and I/O implementations cannot know about one another.

Options

• O1: No change. Let RenderingEngines handle visual property serialization.

  • Each RenderingEngine implementation would need to know how to serialize properties for each file format.

    • Messy and non-scalable.

  • Inhibited: UC1, UC2

  • Awkward: UC3, UC4.

• O2: Same as O1 but serialization format is not specific to any particular format.

  • Converting between generic format and a particular file type's format is just a string mapping.
  • Flexible, but potentially difficult to validate.
  • List of allowable string values would need to be documented somewhere.

  • Awkward: UC3, UC4.

• O3: Let CyNetworkViewReader/WriterFactories handle visual property serialization.

  • All visual property types would need to be exposed as API.

  • Reader/WriterFactory would need to know about VisualProperty types.

  • This may require direct dependency on RenderingEngine implementation bundles (e.g. NodeShape).