Differences between revisions 1 and 4 (spanning 3 versions)

Visual Property Discussion

There are currently two serious issues with the visual property system.
- Serializing a visual property to a format other than what the core supports.
- Programmatic manipulation of visual properties that are not declared as API.
These issues impact the following 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.

Background

How Looking Up Visual Properties Currently Works

VisualProperties can vary from one RenderingEngine implementation to another. In order to access a particular property you need to look it up in a VisualLexicon. The lookup key is a file format-specific name. For example, in GML, the "type" graphics attribute is mapped to the NODE_SHAPE visual property:

How Parsing/Serializing Visual Property Values Currently Works

Instances of VisualProperties are used to serialize and parse property values to and from strings. The implementation of these parsers is the responsibility of RenderingEngine providers.

Legend

Green arrows: Serialization relationships
Blue arrows: Parsing relationships

Specific Issues

[UC1,UC2] Very awkward to serialize visual properties for formats other than XGMML.
- Currently, we need to map between XGMML attribute strings and the target format's strings (e.g. GML).
[UC3] 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.
[UC4] Visual properties of inaccessible types (e.g. org.cytoscape.ding.NodeShape) are awkward to use with discrete mappers programmatically.
VisualLexicon keys are currently format-specific
- Each lexicon implementation needs to know
- Not scalable

Assumptions

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

Options

O1: No change. Let RenderingEngines handle visual property serialization.
- RenderingEngine implementation can only serialize to and from one format.
- 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.
- RenderingEngines can still introduce arbitrary visual property types.
  - However, these would not be accessible programmatically unless the vendor also supplies an API bundle for the new types.

Outdated_Cytoscape_3.0/Mini_Retreat2/VisualPropertyDiscussion (last edited 2011-03-02 16:42:51 by 142)

-  ← Revision 1 as of 2011-03-01 19:54:25 →
  Size: 2134
  Editor: 142
  Comment:
+  ← Revision 4 as of 2011-03-02 15:54:18 →
  Size: 3578
  Editor: 142
  Comment:
-Deletions are marked like this.
+Additions are marked like this.
 Line 3:
-== Existing System ==
+    * There are currently two serious issues with the visual property system.

        * Serializing a visual property to a format other than what the core supports.

        * Programmatic manipulation of visual properties that are not declared as API.

    * These issues impact the following 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.
-Line 5:
+Line 12:
-== 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.
+== Background ==
-Line 11:
+Line 14:
-== Issues ==

    1. Visual properties of inaccessible types (e.g. org.cytoscape.ding.NodeShape) are awkward to set programmatically.
+=== How Looking Up Visual Properties Currently Works ===



VisualProperties can vary from one RenderingEngine implementation to another.  In order to access a particular property you need to look it up in a VisualLexicon.  The lookup key is a file format-specific name.  For example, in GML, the "type" graphics attribute is mapped to the NODE_SHAPE visual property:



{{attachment:lookup-1.png}}



=== How Parsing/Serializing Visual Property Values Currently Works ===



Instances of VisualProperties are used to serialize and parse property values to and from strings.  The implementation of these parsers is the responsibility of RenderingEngine providers.



{{attachment:visualprops-1.png}}



=== Legend ===

    * Green arrows: Serialization relationships

    * Blue arrows: Parsing relationships



== Specific Issues ==

    1. ['''UC1''','''UC2'''] Very awkward to serialize visual properties for formats other than XGMML.

        * Currently, we need to map between XGMML attribute strings and the target format's strings (e.g. GML).

    1. ['''UC3'''] Visual properties of inaccessible types (e.g. org.cytoscape.ding.NodeShape) are awkward to set programmatically.
-Line 14:
+Line 35:
-. Visual properties of inaccessible types (e.g. org.cytoscape.ding.NodeShape) are awkward to use with discrete mappers programmatically.

    1. Not possible to serialize visual properties for formats other than XGMML.
+. ['''UC4'''] Visual properties of inaccessible types (e.g. org.cytoscape.ding.NodeShape) are awkward to use with discrete mappers programmatically.

    1. VisualLexicon keys are currently format-specific

        * Each lexicon implementation needs to know 

        * Not scalable
-Line 22:
+Line 45:
-        * Each RenderingEngine implementation would need to know how to serialize properties for each file format.

            * Messy and non-scalable.
+        * RenderingEngine implementation can only serialize to and from one format.
-Line 26:
+Line 48:
+----

{{attachment:visualprops-2.png}}
-Line 32:
+Line 56:
+----

{{attachment:visualprops-3.png}}
-Line 35:
+Line 60:
-        * Reader/WriterFactory would need to know about VisualProperty types.

        * This may require direct dependency on RenderingEngine implementation bundles (e.g. NodeShape).
+        * RenderingEngines can still introduce arbitrary visual property types.

            * However, these would not be accessible programmatically unless the vendor also supplies an API bundle for the new types.

Diff for "Outdated_Cytoscape_3.0/Mini_Retreat2/VisualPropertyDiscussion"