[Gvsig_desarrolladores] Instrucciones para desarrollar una extensión en gvSIG

[jaume dominguez faus]

Hola, adjunto un poco de documentación relacionada con el tema.

Antes de ponerse a leer, quizá sea un poco necesario explicar cómo está 
esto montado.

gvSIG es una PLUGIN sobre un armazón (framework) llamado fwAndami (el 
andamio para los amigos) que ofrece un entorno de escritorio para 
desarrollar aplicaciones.

Un PLUGIN es cada uno de los directorios que se ven dentro de 
gvSIG/extensiones (personalmente pienso que este directorio debería 
llamarse plugins porque el uso y a veces abuso de la palabra extensión 
confunde al nuevo desarrollador).

Un PLUGIN es el directorio donde se meten EXTENSIONES. Las EXTENSIONES 
son clases que extienden Extension y son  lo que recibe los comandos del 
fwAndami. La definición de qué extensión recibe qué comando cuando se 
pulsa un icono o menú, etc... se hace en los ficheros config.xml del 
PLUGIN que contiene esa EXTENSIÓN

Cuando alguien hace lo que se conoce como una "extensión de gvSIG", en 
realidad lo que está haciendo es una EXTENSIÓN de fwAndami que tiene 
como dependencia previa un PLUGIN de fwAndami llamado gvSIG (que podría 
ser cualquier otro) y  puede entonces, o bien crear otro PLUGIN (con lo 
que crearía un nuevo directorio dentro de gvSIG/extensiones) con su 
EXTENSIÓN o bien incluir su EXTENSIÓN en el PLUGIN gvSIG (con lo que no 
necesitaría crear un directorio nuevo). La primera de las opciones es 
más recomendable, pues separa la extensión de lo que es el core de gvSIG 
con lo que, por ejemplo, tras una actualización no se perdería el 
trabajo propio al sobreescribir ficheros.

Bueno, para detalles técnicos de implementación, remítanse a los 
archivos adjuntos. Y para preguntas pues a la lista de desarrolladores



------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://runas.cap.gva.es/pipermail/gvsig_desarrolladores/attachments/20070110/db821810/Andamideveloperguide.html
------------ próxima parte ------------
En Andami, el class loader de cada plugin delega primero en el classloader del sistemaes decir,
 que si se ejecuta desde eclipse buscará por todos los jars que haya en el classpath del proyecto,
 y si se ejecuta desde la linea de comandos, buscará en la variable de entorno CLASSPATH o en el
 argumento -classpath que se pase como parámetro a java.

Si el class loader del sistema no satisface la búsqueda, se buscará en los jars especificados por el config.xml
 del plugin que intenta cargar la clase y si no se encuentra en dichos jars, se buscará en los jars de los plugins de los cuales depende el plugin que intenta cargar la clase.

Por otra parte, FMap tiene un directorio de drivers en los que vas dejando los jars y automáticamente los procesa FMap.
 Sin embargo, FMap no conoce que es usado por Andami, y de hecho, FMap puede ser usado desde otros entornos, por lo que
 no usa directamente el class loader del plugin que tiene la librería fmap.jar en el config.xml. Usa su propio class loader,
 que está definido en el proyecto driver-manager. Este class loader busca en los jars que hay en el mismo directorio del
 driver y de no encontrarla éstos, delega en el classloader padre. El class loader padre, en el caso de gvSIG con Andami
 es el class loader del plugin que accede al driver.
------------ próxima parte ------------
1 Ejecución en segundo plano.

	Es conveniente que la interfaz esté siempre en funcionamiento,
nunca bloqueada, aunque sea sólo para mostrar al usuario que el
programa está procesando. Para ello hay que realizar las tareas
que puedan tomar demasiado tiempo en un thread a parte. La
clase PluginServices proporciona un método estático 
backgroundExecution al cual se le pasa un objeto Runnable, que
es ejecutado en segundo plano, dejando el thread de la interfaz
libre para responder pero con sus eventos bloqueados con el fin
de que la interfaz responda y se redibuje, pero se ignoren los
eventos que produce el usuario mientras se procesa la petición