3. gvSIG basic architecture

3.1. org.gvsig.tools

La librería tools es una pieza importante dentro de gvSIG. Provee de una serie de utilidades y servicios en los que se apoyan el resto de módulos de gvSIG. La principal funcionalidad que aporta está relacionada con:

• Registro de puntos de extensión
• Inicialización de librerías
• Utilidades para la separación entre API e implementación, (registro de APIs, registro de implementaciones para las APIs, registro de proveedores de servicios SPI o localización de una implementación de un API)
• Monitorización de tareas

Aunque estos son los servicios más importantes que provee la librería además aporta otras utilidades que se pueden considerar estructurales a la aplicación. Como pueden ser:

• Disposables
• Interfaces para manejo de Observers-observables
• Interfaces para el manejo de visitors
• Definición de tipos de datos
• Interfaces base para evaluadores
• Persistencia de objetos

Truco

Puede encontrar información mas detallada sobre como funciona el mecanismo de librerias de gvSIG en org.gvsig.tools.library , sobre los el uso de locators podemos consultar en org.gvsig.tools.locator , y sobre managers podemos encontrar documentación en org.gvsig.tools.service .

Vamos a quedarnos ahora únicamente con tres conceptos básicos que se van a repetir a lo largo del código que vayamos viendo, y están ligados a las utilidades que nos van a permitir separar de forma estricta el API de la implementación:

• Librerías. Se trata de piezas de código asociadas normalmente a un jar que aportan una funcionalidad. Cada una de estas librerías deberán tener una clase que implementa el interface Library, normalmente extendiendo la clase AbstractLibrary. Poseen métodos para inicializar la librería que son invocados en la carga de la misma.
• Managers. Se trata de componentes que aportan una funcionalidad a la aplicación, haciendo las veces de factoría para los distintos servicios que ofrece la librería, así como de configuración de estos. Actúan a modo de singleton, ya que normalmente en la aplicación solo existe una instancia para cada uno de estos componentes. Toda librería tendrá uno a más de estos según la lógica de esta.
• Locators. Se trata de una utilidad que nos permite registrar implementaciones de managers para una librería dada, así como recuperar una implementación de manager de un API en concreto.

Estas tres piezas deberemos tenerlas muy presentes siempre que queramos usar o crear nuevos componentes ya que son los artefactos que nos van a permitir el acceso a las distintas piezas de gvSIG.

3.2. Framework de plugins, Andami

Andami es el framework que utiliza gvSIG para componer la aplicación. Principalmente provee dos tipos de servicios, por un lado de gestión y carga de plugins y por otro, la gestión de ventanas que componen el interfaz de usuario.

En este punto vamos a centrarnos un poquito en la gestión de plugins. Andami proporciona un lanzador para la aplicación que inicializa el sistema de plugins, y se encarga de cargar los plugins que están instalados en la aplicación. Un plugin es una unidad funcional que puede proveer:

• Opciones de menús a instalar en la aplicación
• Nuevos botones y barras de herramientas
• Nuevos proveedores de datos
• Nuevos tipos de documentos

Normalmente, en una instalación de gvSIG, encontraremos una carpeta gvSIG/extensiones. Esta carpeta contiene dentro los distintos plugins que están instalados en la aplicación. Cada plugin está contenido en una carpeta, y dentro de esta, nos encontraremos, siempre, los ficheros:

• config.xml. Es obligatorio que exista. Identifica la carpeta como un plugin. En el encontraremos información sobre:

  • Dónde encontrar las clases de ese plugin

    Truco

    Puede encontrar más información sobre la estructura y distintas etiquetas que están permitidas en este fichero en el documento el fichero config.xml

  • Que clases deben ser cargadas como extensiones (IExtension).

  • Si ese plugin depende de algún otro plugin

  • Qué opciones de menú añade el plugin a la aplicación

  • Qué barras de herramientas y botones añade el plugin.

• package.info, que informa sobre la versión, nombre, identificador o descripción del plugin. Sería algo así como el contenedor de los metadatos del plugin, y nos permite identificarlo para poder actualizarlo o reinstalarlo.

Adicionalmente podemos encontrarnos una carpeta theme, en la que está la configuración del splash de la aplicación, iconos de las ventanas o colores de fondo.

Aunque el mecanismo para añadir nueva funcionalidad a gvSIG es aportando nuevos plugins, estos a su vez contendrán una o más extensiones, siendo estas extensiones las que implementarán la funcionalidad a aportar. Así pues, tendremos que un plugin contendrá extensiones.

Relacionado con el manejo de plugins las principales piezas que nos vamos a encontrar son:

• PluginsLocator, que nos dará acceso al manager de plugins a través de un método estático getManager.
• PluginsManager, que nos proporciona métodos para interrogar sobre qué plugins hay cargados y qué extensión tienen cada uno de estos.
• La clase PluginsServices que representa la instancia de un plugin dado.
• El interface IExtension, que representa una acción o bloque de acciones a incorporar a gvSIG.
• El interface ExclusiveUIExtension, que nos permite controlar la visibilidad de todas las extensiones cargadas en la aplicación.

De estas entidades nos vamos a detener un poco más en la interface IExtension- Esta es la interface que deberemos implementar para poder añadir un nuevo botón u opción de menú. En esta interface nos encontraremos los métodos:

• Initialize, este método se ejecuta cuando se carga la extensión, en la inicialización del plugin. Hay que tener en cuenta que cuando se invoque a este método es posible que no hayan sido cargadas e inicializadas todas las extensiones de gvSIG. Normalmente aquí realizaremos la inicialización de componentes de nuestra extensión que deban ser usados por otras extensiones.
• postInitilize, se invoca en la indización la la extensión. Justo despues de haber invocado al método initialize de todas las extensiones de gvSIG. Normalmente, aquí realizaremos la inicialización de componentes de nuestra extensión que requieran de otras extensiones.
• terminate, se invoca cuando gvSIG precisa descargar esa extensión. Normalmente esto se producirá al cierre de la aplicación. Aquí deberemos asegurarnos que sean liberados los recursos del sistema que tenga reservados nuestra extensión.
• execute. Este método se ejecuta cada vez que el usuario interactúa con el menú o botón de la barra de herramientas asociado a la extensión. Normalmente será donde se implemente la ejecución de nuestra funcionalidad.
• isEnable, es invocado cuando se precisa saber si el interfaz de usuario asociado a la extensión (botones u opciones de menú) deben estar habilitados.
• isVisible, es invocado cuando se precisa saber si el interfaz de usuario asociado a la extensión (botones u opciones de menú) deben estar visibles.

3.3. Ventanas

Truco

Aunque actualmente no existe documentación relacionada con esto para la versión 2 de gvSIG, en general, la documentación existente para gvSIG 1, será válida. Puede encontrarla en Las ventanas de Andami

Andami, además de proveer un mecanismo para la carga y gestión de plugins dispone de un API para la gestión de las ventanas de la aplicación. Actualmente el paradigma usado para la gestión de ventanas es MDI. Sin embargo el propio gestor de ventanas de gvSIG puede ser sustituido para proporcionar otras formas de visualización (SDI, tabs,...).

Las principales entidades que vamos a encontrar en andami relacionadas con el manejo de ventanas serán:

• MDIManagerFactory, es la factoría donde se registra y de donde se obtiene la instancia del MDIManager (hace de Locator).
• MDIManager, representa al gestor de ventanas registrado en gvSIG. Tiene métodos para presentar o cerrar una ventana.
• IWindow, es el interfaz que debe implementar un JPanel para que se presente como una ventana en gvSIG.
• WindowInfo, lo suministran nuestros paneles a través del interfaz IWindow y define las características de nuestra ventana (título, tamaño, tipo,...).

En general siempre que no precisemos de un control fino sobre nuestras ventanas podemos usar el método showWindow del MDIManager para presentar una ventana a partir de un JPanel estándar de swing.

3.4. Algunos plugins de gvSIG

En gvSIG, podemos encontrar una serie de plugins que aportan la funcionalidad base de la aplicación que tienen cierta relevancia respecto al resto de plugins. Estos serían:

• org.gvsig.app.mainplugin. Este plugin provee a gvSIG del grueso de la funcionalidad genérica de la aplicación, así como del acceso básico a datos vectoriales. Aporta:

  • El concepto de proyecto y sus documentos.
  • El documento View
  • Las herramientas básicas de acceso a datos vectoriales de la vista

  Este plugin además de la implementación de estas funcionalidades aporta un manager y un locator importantes de cara a desarrollar otros plugins:

  • ApplicationManager. Se trata de un manager que nos provee de acceso al resto de managers de la aplicación, así como de una funcionalidad básica para acceder a recursos globales de la aplicación. Vendría a ser el objeto que representa a la aplicación gvSIG.
  • ApplicationLocator, que es el locator que nos da acceso al manager de la aplicación (ApplicationManager).

• org.gvsig.app.document.table.app.mainplugin

• org.gvsig.app.document.layout2.app.mainplugin

• org.gvsig.vectorediting.app.mainplugin, provee las funcionalidades de la edición de datos tabulares y vectoriales.

• org.gvsig.geodb.app.mainplugin, añade a la aplicación soporte para acceso a BBDD, como PostgreSQL.

• org.gvsig.i18n.app.mainplugin, añade el soporte para internacionalización a la aplicación.

• org.gvsig.projection.app.jcrs, añade soporte para gestión de CRSs.

• org.gvsig.raster.tools.app.basic, añade soporte raster a gvSIG.

Estos pueden ser algunos de los plugins más importantes en gvSIG en el sentido de que ofrecen una funcionalidad base importante o que son necesarios para que otros plugins puedan funcionar.

Además de estos plugins hay bastantes más plugins en la distribución de gvSIG que pueden ser necesarios o no en función de lo que vayamos a hacer con gvSIG.

3.5. Algunas librerías de relevancia

A la hora de desarrollar con gvSIG, puede sernos útil conocer los plugins existentes, sobre todo las funcionalidades que nos ofrece el ApplicationManager, pero lo realmente importante es controlar qué librerías son las que vamos a necesitar para implementar la funcionalidad que necesitemos.

A partir de la versión 2.0.0 de gvSIG se introdujeron cambios importantes tanto en la forma de construir gvSIG como en la nomenclatura utilizada para identificar los proyectos y librerías que se generan. Sin embargo esto no ha sido un proceso que se dio de repente. Ha ido sucediendo en el transcurso de varios años. Esto ha dado como resultado una falta de homogeneidad en la nomenclatura de los componentes existentes en este momento. A la hora de referirnos a una librería podemos hacerlo por el nombre del proyecto de Eclipse, por el nombre del jar generado o por el nombre de artefacto de Maven. En los proyectos generados recientemente se optó como norma que estos tres nombres debían coincidir, siendo el nombre que se adoptaba para los tres el nombre del artefacto de Maven. Sin embargo proyectos anteriores a esta decisión presentan nombres distintos para cada una de estas cosas. De cara a un desarrollador que vaya a usar gvSIG, lo importante será conocer los nombres de artefacto Maven, ya que normalmente deberá saber con qué artefactos debe fijar las dependencias, siendo menos relevante el nombre del proyecto asociado a ese artefacto.

Las librerías que más pueden cubrir nuestras necesidades en gvSIG serían:

• org.gvsig.tools.lib, contiene utilidades estructurales. Ya se comentó al inicio del documento, así que no nos vamos a extender en ella en este punto.
• org.gvsig.fmap.geometry. Es la librería de manejo de geometrías de gvSIG. Presenta un modelo de geometrías con un API independiente de su implementación.

Truco

Aunque redactadas para gvSIG 2.0.0, existe documentación sobre las librería s de acceso a datos y de geometrias que puede ser interesante de leer ya que casi en su totalidad puede aplicarse a gvSIG 2.2.0. Puede encontrarlas aqui la de DAL y aqui la de geometrias.

• org.gvsig.projection. Es la librería de manejo de sistemas de referencias coordenados de gvSIG.
• org.gvsig.fmap.dal. Es la librería de acceso a datos de gvSIG (Data Access Library). Es usada por todos los proyectos que de una forma u otra precisan acceder a un shape, dxf, una tabla de PostgreSQL, un GML, una capa de un servidor de WFS o un fichero DGN. Presenta un API común para acceso a datos vectoriales y tabulares o para acceso a coberturas.
• org.gvsig.fmap.mapcontext, contiene el API e implementación de capas y mapa a nivel lógico.
• org.gvsig.fmap.control. Contiene componentes swing que se vinculan a los componentes lógicos que se exponen en la librería de DAL y mapcontext, como podría ser un componente visual para presentar un mapa o para presentar una tabla obtenida a partir de DAL.
• org.gvsig.projection.jcrs. Es una implementación del API de proyecciones de org.gvsig.projection.
• org.gvsig.symbology.lib.api. Contiene el API de la librería de simbología de gvSIG.
• org.gvsig.ui. Se trata de una librería que alberga una serie de componentes gráficos de utilidad general.