Cytoscape WikiRFC Name : ... |
Editor(s): ... |
<<TableOfContents: execution failed [Argument "maxdepth" must be an integer value, not "[2]"] (see also the log)>>
About this document
This is an official Request for Comment (RFC) for Cytoscape preference initialization.
For details on RFCs in general, check out the Wikipedia Entry: Request for Comments (RFCs)
Status
Open for public comment
How to Comment
To view/add comments, click on any of 'Comment' links below. By adding your ideas to the Wiki directly, we can more easily organize everyone's ideas, and keep clear records. Be sure to include today's date and your name for each comment. Here is an example to get things started: /Comment.
Try to keep your comments as concrete and constructive as possible. For example, if you find a part of the RFC makes no sense, please say so, but don't stop there. Take the extra step and propose alternatives.
Proposal
Cytoscape is currently initialized in one way: the command line. Plugin writers can access this command line on their own and parse any additional arguments specified on the command line. The problem with this approach is that it exposes the rather messy and cumbersome command line to parts of the system that don't need to know about argument parsing.
I propose changing the command line to handle only a small number of arguments directly (e.g. graphs, attributes, and plugins) and have all other options specified as properties. Properties could be specified in any of the following ways:
- Properties would be read:
- from a default properties included in the jar file.
- from a properties file saved in .cytoscape.
- A command line option would be added to handle general properties (e.g. -P species=human -P canonicalization=yes).
- A command line option would read properties specified by a file name (e.g. --props my.props).
Instead of providing dozens of hard coded get methods in CytoscapeInit, users would access a Properties object and get the property that way (e.g. CytoscapeInit.getProperties().getProperty("canonicalization"); ). The preferences gui could either be clever and infer widgets based on type (e.g. the value of a property is "true" then present the property in the preferences dialog as radio buttons) or keep a scheme similar to what we have.
Plugin writers would access any initialization parameters they need through the specified properties.
Upsides
This will help simplify the initialization interface and ensure modularity: The core and everyone else only ever sees values from CytoscapeInit and Properties.
- This will allow us to easily implement other intialization paths, such as from library mode or embedded window mode.
- Will allow for a cleaner, self-documenting command line.
Downsides
- Interface changes.
- Properties couldn't be checked
Backward Compatibility
Several methods and current schemes for passing information would be deprecated, but no functionality would be lost.
Expected growth and plan for growth
Growth would just be a matter of adding new properties to be handled.