ImportExportMenus

<<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 Add your text here.

For details on RFCs in general, check out the Wikipedia Entry: Request for Comments (RFCs)

Status

Open for comment 2007/01/08

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

The import/export file menus are beginning to look crowded and confusing. There are 3 options for importing attribute files, 2 for importing networks, 5 for exporting networks and 2 for exporting attributes. This can proliferate as plugins add options to the menus to export/import their specific file type.

To clean this up I have a few thoughts. From the user’s point of view it would make most sense to have all possible file types that cytoscape (inc plugins) can open autodetected the way sif/gml files are. This includes attribute/matrix files (though they should continue to have a separate menu option).

Biological Questions / Use Cases

Import/Export dialogs and classes for plugin writers that are simple to understand. Example is the Export Graphics option. User gets a drop down menu of all file types that can be exported after choosing to export. Similarly the menus could be:

Export

• Network
• Attributes
• Graphics
• Vizmap Properties

Export network/attributes could have a drop down like the graphics option does with “human readable” file types for the user to pick.

Import

• Network
• Attributes
• Ontology
• Vizmap Properties

Import network could figure out the right file type via the extension (currently does this for sif/gml/xgmml), import attributes could ask the user when they choose the file what type it is (node/edge/matrix).

General Notes

This might be easiest with a general class “FileHandler” with much of the same functionality of “ImportHandler” but includes methods for getting generic readers and writers (for both attribute/network files). The file type clases (sif, gml etc) could continue inheriting from the handler.

A plugin should then just need to extend the FileHandler for it’s file type then extend the generic reader/writer and add them to the list.

Requirements

Deferred Items

Open Issues

Import/export of files that involve their own dialog such as Excel. Auto-detecting file type for files that use the same extension such as xml files.

Backward Compatibility

Expected growth and plan for growth

References

Implementation Plan

1. Add generic Reader class (similar to GraphReader)

2. Add generic Writer class

3. Add class FileHandler with most of the functionality of ImportHandler, add getReader() and getWriter() methods

4. Refactor ImportHandler to inherit from FileHandler, add ExportHandler for similar export functionality

5. Refactor all export classes to inherit FileHandler

6. Add developer documentation encouraging plugin use of the Handler/Reader/Writer

7. /Implementation Plan

Comments