Difference between revisions of "Component databases"
Soupwizard (talk | contribs) |
Soupwizard (talk | contribs) |
||
| Line 6: | Line 6: | ||
== Functionality To Be Built == | == Functionality To Be Built == | ||
| + | |||
| + | The functionality needed to support the above use case can be broken down into the following: | ||
| + | |||
| + | === OpenRocket Component (ORC) Format === | ||
| + | |||
| + | An open and extensible standard for specifying all relevant details about rocket components. The obvious choice is an XML format. OpenRocket will need to be able to read and write this format. | ||
| + | |||
| + | === Import and Export Tools for the OpenRocket Component Format === | ||
| + | |||
| + | Component data will somehow have to converted into ORC XML files, either by the manufacturers themselves or hobby volunteers. It is unreasonable to expect that manufacturer's staff or hobbyists will have the expertise and time to hand-code component XML files. It is more likely that intermediate spreadsheet files will be created with component data. Therefore, we will need a utility to convert both ways between the ORC XML format and standard comma-separated (CSV) value spreadsheet files. | ||
| + | |||
| + | The utility could be built into the OpenRocket software itself, or could be a separate program. | ||
Revision as of 10:56, 28 August 2011
Introduction
This page is for planning the implementation of component databases in OpenRocket and splitting the implementation into smaller tasks.
Currently in OpenRocket, details about rocket components must be entered by hand every time a rocket is designed. For example, when a body tube is added both the inner diameter, outer diameter, and material need to be specified. However, many of the rocket components generally used are standard commercial items whose design specifications are already know. It would be useful to allow OpenRocket users to, for example, select a body tube by manufacturer and type, and only have to specify the variable dimensions: ie, select an Estes BT-60 tube (which will set the tube dimensions and material), then specify a length of 50 cm.
Functionality To Be Built
The functionality needed to support the above use case can be broken down into the following:
OpenRocket Component (ORC) Format
An open and extensible standard for specifying all relevant details about rocket components. The obvious choice is an XML format. OpenRocket will need to be able to read and write this format.
Import and Export Tools for the OpenRocket Component Format
Component data will somehow have to converted into ORC XML files, either by the manufacturers themselves or hobby volunteers. It is unreasonable to expect that manufacturer's staff or hobbyists will have the expertise and time to hand-code component XML files. It is more likely that intermediate spreadsheet files will be created with component data. Therefore, we will need a utility to convert both ways between the ORC XML format and standard comma-separated (CSV) value spreadsheet files.
The utility could be built into the OpenRocket software itself, or could be a separate program.
Software Design
Tasks
- Design XML format for storing component databases: Component database XML format
- Write schema for the format
- Implement framework for using standard components
- RocketComponentPreset class?
- loadPreset(PresetComponent) method in RocketComponent?
- Remember what is used as a preset component
- When changing critical variables preset component is cleared (e.g. diameter of body tube), but not when changing others (e.g. length of body tube)
- Implement database for storing standard components
- Maintain user-selectable presets list (user can choose which components are in an easy-to-access presets list)
- Implement methods for reading XML format
- Implement methods for reading CSV format
- Implement GUI for component selection
- Preset dropdown
- Button for opening selection dialog
- Dialog allows selecting which components are displayed in the preset list
- Implement GUI for creating components(?)
- Useful for manufacturers
- How to store the preset info in ORK file? Should the entire preset info be included, or just a digest that is used in case the preset is already loaded and available?