RFC

Goal: To set plugins on equal footing with core in terms of using typed properties.

Rationale: Plugins cannot currently modify what properties are available for objects in the properties tab. And more importantly, it cannot modify how values for those properties are entered (ie. change the CellEditor). In this proposal, we're calling these properties "typed properties" because we're effectively specifying what values are valid for the property (ie. giving it a type). The PathVisio core currently has this concept of typed properties (called static properties, implemented in PropertyType) but it is unfortunately hard coded (i.e. it cannot be expanded without recompiling core) and cannot be expanded upon by plugins.

Scope: Properties right now impact the following areas:

#1: association with objects (i.e. ObjectType has specific PropertyTypes associated with it)
#2: mapping to GPML (how to convert the property to GPML and vice-versa)
#3: displaying in properties tab, which has three components: the label,

the value, and the editor (to edit the value)

Proposal: We propose three new concepts:

  1. TypedPropertyClass
  2. TypedProperty
  3. ObjectProperties

TypedPropertyClass: This is the "type" in TypedProperty. It maps directly to org.pathvisio.model.PropertyClass. This allows plugins to define new types (e.g. a dictionary). Each TypedPropertyClass is aware of how to translate itself to/from GPML.

TypedProperty: This defines a typed property. It maps directly to org.pathvisio.model.PropertyType. This allows plugins to define new typed properties.

ObjectProperties: This defines an object and it's associated typed properties. This is a combination of org.pathvisio.model.ObjectType and the property association code in org.pathvisio.model.PathwayElement. ObjectProperties also allows the definition of dependent properties. For example, there can be a control property "species", and depending on what the value of "species" is, different dependent properties will become available.

The changes above handles #1 and #2. To cover #3, I'm introducing a new interface: TypedPropertyClassHandler. Each TypedPropertyClass must also register a TypedPropertyClassHandler that will now how to render and edit the property.

The patch as it stands right now is as minimal as possible to get my ideas across. We tried not to touch any existing code (the exception being making some methods in GpmlFormatImpl1.java public static for use by SampleConversion to avoid code duplication).

The SampleConversion class has sample code on how to move from what we have now to what I'm proposing.

If we do proceed, we may want to reconsider the naming of the classes, because there are too many classes with similar names. We would suggest:

PropertyType -> CoreProperty
ObjectType -> CoreObject
PropertyClass -> CorePropertyType
TypedPropertyClass -> PropertyType

PropertyType, ObjectType and PropertyClass are useful for plugins to get a handle on those defined by the core, and the names I'm suggesting serve to indicate that.

Patch - 12/4

XML vs "hard coded" property associations

There seems to be consensus toward just "hard coding" these associations. While the XML is more flexible, the simplicity of just coding these associations is more advantageous. This could be revisited in the future easily enough, so let's just drop it from the proposal for now.

Attachments