Bases de Datos de componentes - plaa/Modular GitHub Wiki
Esta página es para planificar la implementación de bases de datos de componentes en OpenRocket y dividir dicha implementación en tareas más pequeñas.
Actualmente en OpenRocket, los detalles sobre los componentes del cohete deben introducirse totalmente a mano cada vez que se diseña un cohete. Por ejemplo, cuando se añade un Cuerpo tubular, hay que especificar el diámetro interior, el diámetro exterior, y el material del componente. Sin embargo, muchos de los componentes del cohete generalmente utilizados son productos comerciales estándar cuyas especificaciones ya se conocen. Podría ser útil permitir a los usuarios de OpenRocket que, por ejemplo, seleccione un Cuerpo tubular por el fabricante y el tipo, y sólo tenga que especificar las dimensiones: v.e. seleccionar un tubo Estes BT-60 (el cual ya posee unas dimensiones y un material definido), y luego tan sólo especificar su longitud.
La funcionalidad necesaria para realizar lo anteriormente indicado, se puede dividir como sigue:
Un estándar abierto y extensible para especificar todos los detalles relevantes de los componentes del cohete. La elección obvia es un formato XML. OpenRocket necesitará ser capaz de leer y escribir en este formato.
El formato también podría permitir componentes no-estructurales tales como los motores del cohete, algodón ignífugo o paño de Nomex, etc. - cualquier elemento que se incorpore a un cohete.
La especificación inicial de los campos para el archivo XML y su estructura, puede generarse observando el formato del diseño del cohete ORK y ver cómo se almacena los datos de las diferentes partes.
¿La extensión de la base de datos de componentes debería enlazarse al archivo OpenRocket (ORC)? Sería recomendable que el formato fuera adoptado mejor por otro software... Plaa 19:24, 8 de Octubre de 2011 (UTC)
Los datos de componentes, de alguna manera, tendrán que convertirse en archivos ORC XML, tanto por los propios fabricantes como por aficionados voluntarios. No es razonable esperar que los fabricantes o aficionados posean la experiencia y dispongan del tiempo necesario para codificar archivos XML. Lo mejor es que se generen hojas de cálculo intermedias con los datos de los componentes. a y e 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. Por lo tanto, vamos a necesitar una utilidad para convertir en ambos sentidos entre el formato ORC XML y las hojas de cálculo con los valores estándar (CSV) separados por comas.
La utilidad de importación/exportación podría construirse en el propio programa de OpenRocket, o podría ser un programa aparte.
Los cambios necesarios para que la aplicación OpenRocket pueda utilizar la funcionalidad del componente:
- OpenRocket debe soportar la lectura y la escritura de archivos ORC XML.
- Almacenar todos los datos de los componentes fuera del código del programa (v.e. en archivos ORC XML).
- No permitir al usuario que modifique o reescriba la parte estándar soportada por OpenRocket, en su lugar, permitir al usuario que copie, modifique, y almacene nuevas partes personalizadas.
- Cuando el usuario desee agregar una parte a un diseño, permitir al usuario que seleccione una de la biblioteca de componentes, o que genere una parte nueva utilizando las especificaciones de las partes existentes usando la Intefaz de Usuario (UI).
Una caracterísitica muy útil para los usuarios de OpenRocket podría ser disponer de una biblioteca online de archivos de componentes, una localización normalizada para la última versión de archivos de componentes. Esto podría permitir, al programa OpenRocket, obtener los archivos de componentes más actual por Internet, y proporcionar tanto una UI-web para que la gente vea la biblioteca, como una API-web para permitir al programa que actualice o recupere datos de componentes.
Además de los componentes comerciales para cohetes, la biblioteca podría almacenar componentes no-comerciales, tales como combinaciones de componentes que conforman una pieza grande muy útil. Por ejemplo, puede crearse un dispositivo de eyección a partir de tres componentes más pequeños; un acoplador y dos discos de enganche delgados con orificios taladrados con diferentes patrones.
Con el tiempo, la comunidad cohetera podría construir una biblioteca abierta de componentes e ideas para utilizar en la construcción de cohetes, y de hecho diseños completos de cohetes.
Para los motores de cohete, ¿podríamos obtener datos del motor en bruto de la web thrustcurve.org por medio de sus APIs de Internet?. Podríamos querer utilizar sus datos directamente (cada instancia de usuario de OpenRocket leería de thrustcurve.org), o ¿podríamos extraer datos y almacenarlos en la biblioteca de OpenRocket? (¿o dar la opción de poder realizar alguna de estas cosas?). Una vez que el programa OpenRocket comunique directamente con la web thrustcurve.org (o para el caso, cualquier otra fuente de datos (Estes, etc)) podría ocasionar una sobrecarga no deseada en sus servidores. También, para los usuarios de OpenRocket que no tienen acceso a Internet (o realizan un acceso esporádico), después de haber recuperado todos sus datos de componentes de la biblioteca en formato ORC permite a todos esos usuarios sin conexión actualizar manualmente sus archivos de componentes colocando una instantánea actualizada de la biblioteca (por medio de un pendrive USB, o descargas infrecuentes) en sus máquinas.
Desorden potencial: Alguien tendrá que mantener la biblioteca. La biblioteca podría dividirse en componentes oficiales soportados por OpenRocket (datos de los fabricantes, certificaciones aprobadas y/o Clubs de Modelismo Espacial, etc), y una sección de propósito general para las descargas abiertas.
- Permitir la actualización de archivos de componentes desde la biblioteca de componentes de OpenRocket:
- Desde una conexión online a la biblioteca de APIs-web
- Desde un grupo imágen de archivos actualizados ORC, para usuarios que no tienen acceso a Internet (por ejemplo, lejos de un sitio de lanzamiento).
- Permitir la creación y la subida de componentes personalizados.
- Diseñar bases de datos en formato XML para almacenar los componentes: Component database XML format
- Escribir el esquema para el formato
- Implementar el framework para la utilización de componentes estándar
- ¿Una clase RocketComponentPreset?
- ¿Un método loadPreset(PresetComponent) en RocketComponent?
- Recordar que se está utilizando como componente predefinido
- Cuando se cambian variables críticas, el componente preestablecido se borra (v.e. el diámetro del Cuerpo tubular), pero no cuando se cambian otras variables (v.e. la longitud del Cuerpo tubular)
- Implementar la base de datos para almacenar los componentes estándar
- Mantener una lista predefinida que pueda seleccionar el usuario (el usuario puede elegir qué componentes están en la lista preestablecida de fácil acceso)
- Implementar métodos para la lectura de formatos XML
- Implementar métodos para la lectura de formatos CSV
- Implementar la GUI para la selección de componentes
- Desplegable predefinido
- Botón para abrir el cuadro de diálogo de selección
- El cuadro de diálogo permite seleccionar aquellos componentes que aparecen en la lista predefinida
- Implementar la GUI para la creación de componentes (?)
- Muy útil para los fabricantes
- ¿Como almacenar la información preestablecida en el archivo ORK?. ¿Debería incluirse toda la información preestablecida, o sólo un extracto que sería utilizado en caso de que la información preestablecida ya se haya cargado y esté disponible?