← Revision 1 as of 2011-03-01 19:54:25
2134
Comment:
|
← Revision 2 as of 2011-03-01 20:21:38 →
2307
|
Deletions are marked like this. | Additions are marked like this. |
Line 4: | Line 4: |
{{attachment:visualprops-1.png}} === Legend === * Green arrows: Serialization relationships * Blue arrows: Parsing relationships |
|
Line 22: | Line 28: |
* 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 31: |
---- {{attachment:visualprops-2.png}} |
|
Line 32: | Line 39: |
---- {{attachment:visualprops-3.png}} |
|
Line 35: | Line 43: |
* 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. |
Visual Property Discussion
Existing System
Legend
- Green arrows: Serialization relationships
- Blue arrows: Parsing relationships
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
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.
Visual properties of inaccessible types (e.g. org.cytoscape.ding.NodeShape) are awkward to use with discrete mappers programmatically.
- 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.
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.