Es el bloque que está recuperando los datos directamente de la fuente. Sirve de puente entre la aplicación y los datos. Contiene las clases necesarias para acceder a los datos, escribir datos en una fuente, así como las propiedades de acceso a fuentes remotas.

Diagrama de bloques de Subdriver

RemoteServices: Contiene las herramientas necesarias para unificar el acceso a datos remotos.

• Drivers: Gestionan los distintos tipos de datos soportados por gvSIG.
• DriverManager: Proporciona la carga y el acceso a los drivers disponibles en la aplicación tanto alfanuméricos como espaciales.
• WriterManager: Proporciona la carga y el acceso a los writers disponibles en la aplicación tanto alfanuméricos como espaciales.
• Writers: Permiten las operaciones de escritura sobre los distintos tipos de formatos soportados.
• VectorialSources: Proporciona acceso a los datos con las geometrías.
• DataSources: Proporciona acceso a los datos alfanuméricos.
• RasterSources: Proporciona acceso a los datos de tipo ráster.

Vamos a mostrar una perspectiva general de los bloques funcionales de Andami, explicando la funcionalidad aportada por cada uno.

Diagrama de bloques funcionales de Andami

La filosofía en la que se apoya la extensibilidad de Andami es la siguiente: existen unas clases especiales, llamadas extensiones, que implementan la interfaz IExtension, la cual incluye un método execute() (entre otros). En el fichero config.xml del plugin, se definen una serie de elementos de interfaz de usuario que se van a añadir a la aplicación (herramientas, menús y controles de la barra de estado), y se asocia cada uno de estos elementos con una extensión. En concreto, cuando el usuario pinche en una herramienta o una entrada de menú, Andami ejecutará el método execute de la extensión asociada. De esta forma, la extensión realizará las acciones necesarias para ejecutar la operación solicitada, posiblemente apoyándose en otras clases o librerías del plugin.

Vemos por tanto que la extensión es el punto de acceso a las nuevas funcionalidades aportadas por el plugin, y que los elementos de interfaz de usuario (definidos en el config.xml) junto con la extensión asociada constituyen el nexo entre el resto de la aplicación y el plugin.

<?xml version="1.0" encoding="ISO-8859-1"?>
<plugin-config>
  <depends plugin-name="com.iver.cit.gvsig" />
  <libraries library-dir="./lib"/>
  <resourceBundle name="text"/>
  <extensions>
    <extension class-name="com.iver.cit.gvsig.wfs.WFSClientExtension"
      description="Support to access WFS"
      active="true"
      priority="1">
    </extension>
    <extension
      class-name="com.iver.gvsig.centerviewpoint.CenterViewToPointExtension"
      description="Haces zoom a partir de un par de coordenadas"
      active="true">
        <menu text="Vista/Centrar_la_Vista_sobre_un_punto"
          tooltip="Centrar_la_Vista_sobre_un_punto" 
          action-command="CENTERVIEWTOPOINT" 
          icon="images/centerviewtopoint.png" />
        <tool-bar name="com.iver.cit.gvsig.Herramientas">
          <action-tool icon="images/centerviewtopoint.png"
            action-command="CENTERVIEWTOPOINT"
            tooltip="Centrar_la_Vista_sobre_un_punto"
            enable-text="debería de estar activada" last="true"/>
        </tool-bar>
    </extension>
  </extensions>
</plugin-config>

Etiquetas permitidas

A continuación, se describe en detalle cada una de las etiquetas permitidas. No obstante, dentro de la distribución del código fuente de gvSIG, existe un fichero llamado plugin-config.xsd, situado dentro de _fwAndami/schemas, donde se describen formalmente todas las etiquetas permitidas y el tipo de valores que aceptan. Este fichero está escrito en lenguaje XSD Schema, un lenguaje de descripción de sintaxis XML. Ese fichero debe constituir la referencia principal a la hora de conocer las etiquetas permitidas.

Jerarquía de etiquetas válidas de plugin-config.xml

Cabecera

El fichero XML debe ir encabezado por una cabecera como la siguiente:

<?xml version="1.0" encoding="UTF-8"?>

Es importante que el primer carácter < sea el primero del fichero (es decir, que no haya ningún carácter en blanco antes de la cabecera), de lo contrario el fichero se leerá incorrectamente.

• version: Indica la versión de estándar XML que vamos a usar (en nuestro caso, "1.0")
• encoding: Indica la codificación de caracteres con la que vamos a salvar el fichero en disco. La codificación que especifiquemos aquí debe coincidir con la codificación que realmente usemos en el momento de salvar el fichero (los editores de texto normalmente permiten especificar la codificación en algún apartado). Algunas codificaciones típicas son "UTF-8", "ISO-8859-15" e "ISO-8859-1"

<plugin-config>

Etiqueta que simplemente marca el inicio y el fin del fichero de configuración; es la raíz del árbol XML.

<resourceBundle>

Indica el nombre base que tendrán los ficheros de traducción. Por ejemplo, si escribimos <resourceBundle name="text"/>, los ficheros de traducciones se llamarán text.properties, text_en.properties, etc.

<depends>

Indica los plugins de los que va a depender nuestro plugins, a nivel de librerías. Esto significa que si deseamos usar algunas clases o librerías que estén en un plugin distinto, debemos declarar una dependencia de ese plugin. Debe haber una entrada <depends> por cada plugin del que dependamos.

Las dependencias determinan también el orden de carga de plugins, de forma que un plugin siempre se carga después de que sus dependencias han sido ya cargadas. Normalmente, todos los plugins dependen del plugin gvSIG (com.iver.cit.gvsig), por lo que este plugin se carga el primero.

<libraries>

Establece el directorio del que se leerán las librerías de nuestro plugin. Normalmente suele usarse <libraries library-dir="."> (para indicar el directorio raíz del plugin), o bien <libraries library-dir="lib"> (para indicar el subdirectorio lib). Dos plugins distintos pueden tener versiones distintas de una misma librería, y ambas funcionarán correctamente sin interferencias, salvo en los siguientes supuestos:

• Si un plugin A declara una dependencia de plugin B, y ambos poseen la misma librería pero en diferente versión: el plugin B usará su propia versión sin ningún problema; el plugin A usará su propia versión si el plugin B se carga después de A, en caso contrario se usará la versión de B.
• Si existe un plugin A que posee una librería, y esta librería está también en el CLASSPATH inicial de Andami (declarado al lanzar Andami), el plugin A usará la versión presente en el CLASSPATH inicial.

<label-set>

Indica el comienzo de un grupo de etiquetas (label) para la barra de estado. Cada grupo de etiquetas (label-set) está asociado a una clase, y sólo es visible cuando la ventana visible es instancia de dicha clase. Acepta los siguientes atributos:

• class-name Nombre de la clase asociada a este label-set. Las etiquetas del label-set sólo serán visibles cuando la ventana activa sea instancia de esta clase.

<label>

Instala una etiqueta (una caja de texto no editable) en la barra de estada. La etiqueta siempre pertenece a un grupo de etiquetas (label-set) y sólo será visible cuando lo sea el label-set. Acepta los siguientes atributos:

• id Identificador (nombre) de la etiqueta. Se usará para acceder a la etiqueta y escribir sobre ella.
• size Anchura de la etiqueta (en píxeles).

<extensions>

Marca el inicio de la lista de extensiones.

<extension>

Declara una extensión de Andami. Principalmente, la declaración incluye el nombre de la clase Java que implementa esta extensión, y una lista de elementos de interfaz de usuario que deberán añadirse a la aplicación y estarán asociados con esta extensión. <extension> acepta los siguientes atributos:

• class-name Nombre de la clase que implementa esta extensión. La clase debe estar localizada en alguna de las librerías incluidas en el plugin.
• description Descripción de la funcionalidad aportada por la extensión.
• active Establece si la extensión va a estar activa o no. Si no está activa, es como si no existiese.
• priority La prioridad de la extensión determina el orden de carga respecto a otras extensiones del mismo plugin. Una extensión con una prioridad menor se cargará antes que otra extensión con una prioridad mayor. Hay que tener en cuenta que las dependencias entre plugin son las que determinan el orden de carga de plugins, por tanto si lo que queremos es cambiar el orden de carga de dos extensiones que están en plugins distintos, debemos modificar las dependencias entre ellos, no la prioridad. Por convención, se usan valores entre 1 y 99999 (aunque realmente se admiten rangos mayores). Para una extensión sin necesidades especiales, podemos omitir el valor prioridad, o darle un valor de 2000.

<tool-bar> Crea una barra de herramientas (grupo de herramientas) con el nombre dado. Dentro esta etiqueta se anidarán los botones que deseamos añadir a esta barra de herramientas. Diferentes extensiones pueden añadir botones a la misma barra de herramientas, basta con que se llamen de la misma forma. <tool-bar> acepta los siguientes atributos:

• name Nombre de la barra de herramientas. Sirve para agrupar botones de extensiones diferentes(si el nombre de la tool-bar es el mismo, se añadirán a la misma tool-bar. También se mostrará en la lista de barras de herramientas, traducido al idioma correspondiente, por lo que name debe considerarse como una clave de traducción.
• position Sirve para establecer la posición de la barra de herramientas respecto a otras. Una tool-bar con un valor de position más bajo que la de otra tool-bar indica que la primera tool-bar se situará más a la izquierda que la segunda. Si diferentes extensiones definen diferentes positions para la misma barra de herramientas, sólo se tendrá en cuenta la position definida en la extensión de mayor prioridad (la que tenga un valor de priority más bajo).
• is-visible Determina si la tool-bar estará inicialmente visible u oculta. Esto puede cambiarse posteriormente por código, o bien por el usuario desde los menús.

<action-tool>

Una action-tool es una herramienta (un botón) que lanza una acción concreta. El mecanismo exacto es el siguiente: el usuario pulsa el botón, Andami recibe el evento de pulsado, consulta la extensión asociada a este botón y lanza el método execute(String actionCommand) de dicha extensión, pasándole como parámetro el comando (action-command) definido para este botón. action-tool acepta los siguientes atributos:

• action-command Especifica el comando que deseamos que sea ejecutado por la extensión asociada. Se puede omitir si la extensión va a tener un solo botón (o menú, etc) asociado, o bien si todos los botones (menús, etc) realizarán la misma acción.
• name Nombre del botón. Útil si posteriormente deseamos obtener el botón para cambiarle el icono, por ejemplo.
• position Sirve para establecer la posición del botón dentro de la barra de herramientas. Un botón con un valor position más bajo que la de otro botón se situará más a la izquierda que el segundo botón. Si diferentes botones poseen la misma posición o no poseen posición, se ordenarán arbitrariamente. Un botón que posea posición siempre irá a la izquierda de un botón sin posición. No obstante, no se recomienda omitir este atributo.
• icon Icono que se mostrará dentro del botón. La ruta de la imagen debe ser relativa al directorio raíz del plugin.
• text Texto (opcional) a mostrar junto al icono.
• tooltip Texto que se mostrará en el globo de texto (tooltip) que aparece al mantener quieto el ratón sobre el botón durante unos segundos.
• enable-text Texto que informa al usuario de las condiciones que deben producirse para que este botón esté activo. Cuando el botón está visible pero desactivado, el tooltip muestra este texto en vez del normal, para que el usuario sepa qué debe hacer para usar esta herramienta.
• last Indica que deseamos dejar un espacio extra a la derecha de este icono. Normalmente se usa en el último icono de una barra de herramientas, para marcar más la separación con la barra de herramientas contigua.

<selectable-tool>

Una selectable-tool es un botón que puede estar pulsado (herramienta seleccionada) o no pulsado (herramienta no seleccionada), y no ejecuta una acción como la action-tool, sino que indica un cambio de estado (por ejemplo, "Zoom Más seleccionado", "Zoom Menos seleccionado", etc). Cuando una selectable-tool está pulsada, las demás están no-pulsadas. Si pulsamos en otra selectable-tool, la anterior deja de estar pulsada. La selectable-tool seleccionada en cada momento va asociada a la ventana activa: si cambiamos de ventana activa, se carga la herramienta seleccionada asociada a la nueva ventana activa. Si volvemos a la ventana anterior, se vuelve a seleccionar la herramienta asociada a la ventana anterior.

Detalle de dos herramientas seleccionables (la izquierda está seleccionada)

La etiqueta selectable-tool admite los mismos atributos que action-tool, casi todos con la misma semántica, salvo action-command que en este caso indica la herramienta seleccionada. Adicionalmente, selectable-tool permite:

• is-default Determina si esta herramienta estará seleccionada inicialmente.

<menu> Crea una entrada de menú. El menú funcionará a todos los efectos como una action-tool, es decir, al pinchar en el menú se lanzará el método execute() de la extensión asociada, pasándole como parámetro el action-command especificado por el menú. Admite los siguientes atributos:

• action-command Especifica el comando que deseamos que sea ejecutado por la extensión asociada. Se puede omitir si la extensión va a tener un solo botón (o menú, etc) asociado, o bien si todos los botones (menús, etc) realizarán la misma acción.
• text Determina la localización y el texto a mostrar por la entrada del menú. text debe tener la forma "Archivo/Abrir". Cada porción separada por barras (/) indica un contenedor de menú, como Archivo, excepto la última porción que indica el texto a mostrar en la entrada misma. Por ejemplo, "Archivo/Abrir" creará una entrada llamada Abrir dentro del menú Archivo. Otro ejemplo: "Archivo/Plantillas/Abrir Plantillas" creará una entrada Abrir Plantillas dentro del submenú Plantillas, dentro del menú Archivo. Si los menús contenedores no existiesen, se crearían automáticamente. Hay que tener en cuenta que el texto real mostrado en los menús y submenús se traduce al idioma seleccionado por el usuario, por lo que cada porción de texto empleado aquí constituye una clave de traducción.
• position Sirve para establecer la posición de la entrada de menú dentro del submenú en el que esté situada. Una entrada con un valor position más bajo que la de otra entrada se situará más arriba (más cerca del inicio del menú) que la segunda entrada. Si diferentes entradas poseen la misma posición, o no poseen posición, se ordenarán arbitrariamente. Una entrada que posea posición siempre estará más arriba que una entrada sin posición. No obstante, no se recomienda omitir este atributo.
• icon Icono que se mostrará dentro del botón. La ruta de la imagen debe ser relativa al directorio raíz del plugin.
• tooltip Texto que se mostrará en el globo de texto (tooltip) que aparece al mantener quieto el ratón sobre el botón durante unos segundos.
• enable-text Texto que informa al usuario de las condiciones que deben producirse para que este botón esté activo. Cuando el botón está visible pero desactivado, el tooltip muestra este texto en vez del normal, para que el usuario sepa qué debe hacer para usar esta herramienta.
• key La key es el carácter que forma la combinación de teclas necesaria para lanzar este menú. La combinación se forma usando el modificador de ese sistema operativo + key. Por ejemplo, en Windows el modificador es la tecla ALT, y la key de la entrada de menú Añadir capa es O, así que pulsando ALT+O nos aparece el diálogo de añadir capa.
• mnemonic El mnemonic es la tecla que activará esta entrada de menú cuando el menú esté desplegado y tenga el foco. Por ejemplo, cuando el menú Archivo está seleccionado, y pulsamos la tecla A, aparece el diálogo de abrir proyecto porque A es el mnemotécnico de la entrada Abrir proyecto.
• is_separator Atributo que indica que deseamos añadir un separador en esta posición de la barra de menús. Es un atributo especial que debe añadirse en una entrada de menú aparte, ya que no añade un separador debajo de la entrada actual, sino que transforma la entrada actual en un separador (y por tanto no se mostrará el texto ni el icono, ni se podrá pulsar sobre ella).

<combo-scale> Añade a la barra de estado un control de tipo combo box (control que permite elegir un valor de una lista de valores, o bien escribir el valor deseado), con una etiqueta de texto a la izquierda describiendo su función. Acepta los siguientes atributos:

• name Nombre del control. Debería ser diferente al nombre de cualquier otro control.
• label El texto que será mostrado a la izquierda del combo box.
• elements Una lista de valores numéricos separados por punto y coma. Cada valor constituirá una entrada del combo box.
• value Valor que estará inicialmente seleccionado. Si se omite, el primer elemento estará seleccionado.
• action-command Especifica el comando que deseamos que sea ejecutado por la extensión asociada. Se puede omitir si la extensión va a tener un solo botón (o menú, etc) asociado, o bien si todos los botones (menús, etc) realizarán la misma acción.

Detalle de un combo-scale

Como ya hemos explicado, las extensiones son clases que sirven de puente entre la funcionalidad básica de gvSIG y las funcionalidades aportadas por nuestro plugin. La extensión recibirá notificación de las acciones realizadas por el usuario, y ejecutará el código apropiado en respuesta a esas acciones (posiblemente usando otras clases de nuestro plugin).

El siguiente diagrama muestra de forma esquemática todas las clases que vamos a explicar en este capítulo y sus relaciones:

Diagrama de las clases implicadas en la creación de extensiones

Todas las extensiones implementan la interfaz IExtension, que incluye los siguientes métodos:

• public void initialize() Una vez se leen y ordenan todas las extensiones presentes en los plugins, se llama a este método para cada una de ellas, de forma secuencial siguiendo el orden definido en la prioridad de las extensiones.
• public void postInitialize() Una vez se han inicializado todas las extensiones, se llama a este método para cada una de ellas, siguiendo el mismo orden de antes.
• public void terminate() Al salir de la aplicación, se llama a este método para cada una de las extensiones, siguiendo un orden secuencial inverso al que se siguió en la inicialización (es decir, la última extensión que se inicializó es la primera que se finalizará, y la primera extensión que se inicializó será la última en ser finalizada).
• public void execute(String actionCommand) En el config.xml se definen elementos de la interfaz de usuario (botones, menús, etc) que están asociados a una extensión. Cuando el usuario pulsa en uno de estos elementos de la interfaz, se busca la extensión asociada y se llama a este método. Los botones, menús, etc pueden tener asociado una cadena que actúa como identificador de comando (action command). Cuando se llama al método execute, se pasa como parámetro el actionCommand asociado al botón que se pulsó. De esta forma, si tenemos varios botones, menús, etc asociados con esta extensión, podemos discriminarlos comprobando el actionCommand que recibimos. Normalmente, será en este método donde escribiremos las principales acciones de nuestra extensión (abrir un asistente, comenzar algún procesamiento, etc).

Los dos siguientes métodos determinan si la extensión (y sus elementos de interfaz de usuario asociados) serán visibles y estarán activos. Estas propiedades se comprueban para todas las extensiones cada vez que se cambia de ventana activa y también justo después de procesar un evento de interfaz de usuario (es decir, después de llamar al método execute de una extensión).

• public boolean isEnabled() Los elementos de interfaz de usuario (botones, menús, controles de la barra de estado) asociados a esta extensión estarán activados (o desactivados) dependiendo del valor devuelto por este método. Cuando un botón está desactivado, aparece en gris claro y no es posible pulsar sobre él.

Detalle de un menú activo y otro desactivado.

• public boolean isVisible() Los elementos de interfaz de usuario (botones, menús, controles de la barra de estado) asociados a esta extensión estarán visibles (o invisibles) dependiendo del valor devuelto por este método. Cuando un botón está invisible, no se mostrará independientemente del valor de isEnabled().

Los dos métodos siguientes sólo se usan con el mecanismo ExclusiveUIExtension, que permite a una extensión tomar el control de la interfaz y activar o desactivar (mostrar u ocultar) otras extensiones. Esto puede usarse para crear extensiones que personalicen gvSIG (por ejemplo, una extensión que transforme gvSIG en un simple visor de cartografía):

• public boolean isEnabled(IExtension extension) Decide si la extensión pasada como parámetro estará activada o no, ignorando el valor del método isEnabled de la propia extensión.
• public boolean isVisible(IExtension extension) Decide si la extensión pasada como parámetro estará visible o no, ignorando el valor del método isVisible de la propia extensión.

Salvo que tengamos una necesidad muy especial, normalmente no implementaremos directamente la interfaz IExtension, sino que extenderemos la clase abstracta Extension, que a su vez ya implementa IExtension. Esto nos ofrece una cierta tranquilidad de futuro en el funcionamiento de nuestra extensión, ya que si se añadiese algún método a la interfaz IExtension, este método se implementaría en la clase Extension de forma que nuestra extensión seguiría funcionando sin cambios (a no ser que necesitase un comportamiento para el nuevo método distinto del implementado en Extension).

La interfaz HiddableExtension y la clase ExtensionDecorator permiten cambiar la visibilidad de una extensión (y sus controles asociados) en tiempo de ejecución, ignorando el valor que indique la propia extensión en el método isVisible. De esta forma podemos instalar una extensión que oculte un conjunto de otras extensiones, creando un gvSIG personalizado (que sólo mostraría las extensiones deseadas).

La interfaz HiddableExtension sólo contiene dos métodos:

• public void setVisibility(int state) Permite definir una visibilidad para una extensión, que prevalece sobre la visibilidad definida en el método isVisible() de la propia extensión. Los valores de visibilidad aceptados incluyen: ExtensionDecorator.INACTIVE (el Decorator está desactivado y por tanto se obedecerá a la establecido en el método isVisible() de la propia extensión), ExtensionDecorator.ALWAYS_VISIBLE (la extensión estará siempre visible) y ExtensionDecorator.ALWAYS_INVISIBLE (la extensión estará siempre invisible).
• public int getVisibility() Consulta la visibilidad que se ha adjudicado a la extensión. Los valores devueltos pueden ser ExtensionDecorator.INACTIVE, ExtensionDecorator.ALWAYS_VISIBLE o ExtensionDecorator.ALWAYS_INVISIBLE.

La clase ExtensionDecorator implementa la interfaz HiddableExtension. Cada extensión cargada por Andami posee un ExtensionDecorator asociado, que podemos obtener para cambiar la visibilidad de esa extensión. Mostramos como ejemplo el código necesario para ocultar la extensión "com.iver.cit.gvsig.StartEditing", que es la que permite poner una capa en edición. De esta forma, estaríamos desactivando las capacidades de edición de gvSIG:

ExtensionDecorator decorator = PluginServices.getDecoratedExtension(com.iver.cit.gvsig.StartEditing.class);
decorator.setVisibility(ExtensionDecorator.ALWAYS_INVISIBLE);

Por supuesto, para llevar a cabo con éxito una personalización de gvSIG, necesitamos conocer las extensiones que deseamos ocultar. Además, para poder acceder correctamente a la clase de la extensión a desactivar (en este ejemplo, com.iver.cit.gvsig.StartEditing.class) necesitamos declarar una dependencia del plugin que contenga la extensión, de lo contrario obtendremos una excepción de tipo ClassNotFoundException al ejecutar ese código. En este caso, com.iver.cit.gvsig.StartEditing.class está contenido en el plugin com.iver.cit.gvsig.cad, por tanto necesitamos añadir al config.xml de nuestro plugin una línea como la siguiente:

<depends plugin-name="com.iver.cit.gvsig.cad" />

Téngase en cuenta que cualquier extensión puede usar este mecanismo en cualquier momento para ocultar o mostrar otra extensión. Para evitar comportamientos impredecibles, ExtensionDecorator sólo debería usarse en extensiones especiales que deseen personalizar gvSIG, y no deberían instalarse dos extensiones de este tipo al mismo tiempo (de lo contrario, es posible que lo que una de ellas vaya ocultando, la otra lo vaya mostrando y será difícil prever el resultado final, salvo que ambas extensiones realicen estas ocultaciones de forma coordinada).

El mecanismo ExclusiveUIExtension permite realizar algo similar a lo que se consigue con ExtensionDecorator, pero en este caso existe una única extensión que decidirá el estado de las demás. Es decir, con ExtensionDecorator cualquier extensión puede modificar el estado de las demás. Con ExclusiveUIExtension, se definirá una única extensión que tendrá la capacidad de mostrar/ocultar y activar/desactivar el resto de extensiones.

En cualquier caso, ambos mecanismos pueden usarse al mismo tiempo y ExclusiveUIExtension respetará lo definido por ExtensionDecorator, de forma que si ExtensionDecorator define una visibilidad ALWAYS_VISIBLE (siempre visible), la extensión estará visible pese a que ExclusiveUIExtension defina la extensión como oculta. Es decir, ExclusiveUIExtension sólo actuará en caso de que el ExtensionDecorator esté inactivo (modo ExtensionDecorator.INACTIVE). En cualquier caso, ExtensionDecorator sólo actúa sobre la visibilidad de la extensión, mientras que el mecanismo ExclusiveUIExtension puede definir también si la extensión está activa (enabled) o no.

Para usar ExclusiveUIExtension necesitamos:

• Tener una extensión que implemente correctamente los métodos isEnabled(IExtension extension) y isVisible(IExtension extension). Esta extensión actuará como ExclusiveUIExtension, decidiendo el estado (visible/invisible, activa/desactivada) del resto de extensiones.
• Registrarse como ExclusiveUIExtension en Andami, dentro del método initialize de nuestra extensión, utilizando el método PluginServices.setExclusiveUIExtension().
• Otra opción equivalente a registrarnos utilizando el método setExclusiveUIExtension consiste en sumistrar un parámetro de arranque a gvSIG. El parámetro es el siguiente: ExclusiveUIExtension=NombreDeExtension, donde NombreDeExtension debe sustituirse por el nombre de la extensión mencionada en el punto anterior.
  • En Linux, esto puede conseguirse bien editando el lanzador gvSIG.sh añadiéndole este parámetro antes del símbolo "$@", o bien pasándole el parámetro a dicho lanzador.
  • En Windows se puede modificar el fichero gvSIG.ini, en la línea que empieza por command, añadiendo el parámetro justo antes del símbolo #ARGS#. También es posible pasar el parámetro al comando gvSIG.exe en el momento de su ejecución.

Andami facilita la creación y gestión de ventanas, ofreciendo una interfaz de ventana que se abstrae de los diferentes tipos de ventanas de Java Swing. De esta forma, cuando queramos crear una ventana, en vez de pensar en ventanas de Swing, simplemente crearemos un panel que implemente la interfaz IWindow y le pediremos a Andami que cree una ventana con las propiedades que deseemos. En función de las propiedades pedidas y el skin instalado, se creará un tipo de ventana distinto (JInternalFrame, JDialog, etc), pero esto será indiferente para nosotros. Para no confundir la ventana real (creada por Andami) con el contenido (creado por nosotros y que implementa la interfaz IWindow), de ahora en adelante usaremos los términos frame , marco o ventana real para referirnos a la ventana creada por Andami, y ventana para referirnos al contenido (que implementa IWindow).

Cuando hablamos de ventanas de Andami, podemos hacer una primera distinción entre ellas: ventana principal, y resto de ventanas. La ventana principal (MainFrame) es la que contiene las barras de herramientas, la barra de estado y (en algunas plataformas) la barra de menús. Esta ventana no está bajo control del gestor de ventanas, sino que se accede a ella usando un método específico de la clase PluginServices. El resto de ventanas sí están bajo el control del gestor de ventanas (MDIManager), al cual debemos dirigirnos para crearlas, cerrarlas o cambiar sus propiedades.

Diagrama de las principales clases implicadas en la gestión de ventanas

• En el capítulo Gestión de ventanas podemos aprender como crear ventanas y cómo manipularlas haciendo uso del gestor de ventanas (MDIManager).
• En el capítulo La ventana principal podemos encontrar más información sobre las posibilidades ofrecidas por dicha ventana (MainFrame).

Mientras la gestión de plugins se incorpora directamente en Andami, la gestión de ventanas se delega en los llamados skins de Andami. Andami ofrece unas interfaces y objetos para la gestión de ventanas: IWindow, MDIManager, WindowInfo, IWindowListener, SingletonWindow... dichas interfaces deben ser implementadas por el skin, quien realmente realizará la gestión de ventanas. De esta forma, se podría llevar a cabo una gestión de ventanas distinta, implementando un skin distinto. Actualmente sólo existe un Skin implementado, llamado CorePlugin. Formalmente, es un plugin más de Andami, pero con la particularidad de que Andami no arrancará si CorePlugin (u otro skin) no está instalado. Los skins deben incluir una extensión especial, que implemente IExtension y MDIManager, y que se define en el config.xml con la etiqueta skin-extension.

Clases principales de CorePlugin y clases relacionadas de Andami

Cualquier ventana que deseemos crear a través de Andami debe implementar la interfaz IWindow. Conviene aclarar que IWindow no será una ventana de Swing, sino el contenido de la ventana (normalmente una clase que herede de JPanel a la que añadiremos todos los componentes necesarios). La ventana propiamente dicha (frame), será creada por Andami y no tendremos acceso directo a ella.

La interfaz IWindow sólo posee un método, que especifica las propiedades iniciales que deberá tener la ventana creada (posición, tamaño, tipo, título, etc.):

public WindowInfo getWindowInfo()

Este método será usado por Andami en el momento de la creación de la ventana real para determinar las propiedades y el tipo de ventana a crear. El objeto devuelto por este método es de tipo WindowInfo, el cual describe las propiedades de una ventana de Andami (explicado en la sección siguiente). Debemos hacer hincapié en que este método sólo devuelve las propiedades iniciales y que por tanto no debemos usar este método para obtener o modificar las propiedades de la ventana, para esta tarea nos dirigiremos al gestor de ventanas.

La mayoría de las ventanas que creemos no implementarán directamente IWindow, sino una interfaz más específica, SingletonWindow, que asocia un modelo a cada ventana. Este modelo se utiliza para dotar de identidad a las ventanas, de forma que al intentar crear una ventana con un modelo que ya esté asociado a otra ventana, obtendremos una referencia a esta segunda ventana.

El objeto WindowInfo almacena las propiedades de una ventana de Andami, de forma que existe un objeto WindowInfo asociado a cada ventana (IWindow) creada por Andami. Puede usarse tanto para consultar las propiedades actuales de la ventana como para modificarlas. Al modificar una propiedad de WindowInfo, este ventana se refleja inmediatamente en la ventana asociada.

Atendiendo el comportamiento que tendrá la ventana respecto a las otras, existen ventanas de tres tipos: normales, modales y modeless.

• Llamamos ventana modal a aquella que siempre están encima de las otras y además no permite que el foco pase a ninguna de las otras. Cuando creamos una ventana modal, no podremos interactuar con los menús, herramientas, etc., de la ventana principal hasta que cerremos la ventana modal (ni tampoco podremos interactuar con el resto de ventanas). Además, las ventanas modales suspenden el hilo de ejecución principal de la aplicación, de forma que el código de nuestra extensión no continuará ejecutándose hasta que cerremos la ventana modal.
• Llamamos ventana modeless a aquella que siempre está encima de las otras pero a diferencia de la modal sí permite que el foco pase a otras ventanas, y por tanto permite interactuar con los menús y herramientas de la ventana principal y con el contenido de otras ventanas.
• Ventanas normales son las que pueden estar encima o debajo de las otras de forma normal, es decir, las que no imponen ninguna restricción especial respecto al foco o a la superposición a otras ventanas.

Debemos tener en cuenta que las ventanas modeless sólo lo serán respecto a las ventanas normales; es decir, una ventana modeless siempre estará encima de las ventanas normales existentes, pero podrá estar encima o debajo de otra ventana modeless, dependiendo de qué ventana seleccionemos.

De forma similar, las ventanas modales sólo lo serán respecto a las ventanas normales o modeless; es decir, siempre estarán encima de las ventanas normales o modeless existentes, pero podrán estar encima o debajo de otras ventanas modales, dependiendo de qué ventana esté seleccionada.

El tipo de ventana que se creará a partir de un objeto WindowInfo depende de las propiedades suministradas al constructor del objeto. Por ejemplo, para crear una ventana modal, el método getWindowInfo() de la ventana deberá contener el siguiente código:

WindowInfo windowInfo = new WindowInfo(WindowInfo.MODALDIALOG);
return windowInfo;

Para crear una ventana modeless:

WindowInfo windowInfo = new WindowInfo(WindowInfo.MODELESSDIALOG);
return windowInfo;

Para crear una ventana normal:

WindowInfo windowInfo = new WindowInfo();
return windowInfo;

Existen otras propiedades que podemos especificar en el constructor, que añadiremos usando el operador de suma binaria |:

• WindowInfo.RESIZABLE Especifica que se permitirá al usuario redimensionar la ventana. Si no se incluye, la ventana no será redimensionable (tendrá tamaño fijo).
• WindowInfo.MAXIMIZABLE Especifica que la ventana podrá ser maximizable. Una ventana maximizable posee dos modos: modo maximizado, en el cual se empotra en la ventana principal de Andami, ocupando todo su espacio, y modo no maximizado, en el cual la ventana posee su tamaño normal. Para pasar de un modo a otro, el usuario debe pulsar el botón de Maximizar/Restaurar (en la barra del título). El objeto WindowInfo posee también unos métodos para cambiar este estado a nivel de código. Si no se especifica la propiedad MAXIMIZABLE, la ventana no será MAXIMIZABLE (siempre estará en el estado no maximizado.
• WindowInfo.ICONIFIABLE Especifica que se permitirá al usuario minimizar la ventana. Cuando la ventana se minimiza, desaparece y en su lugar aparece un botón en la parte inferior izquierda de la ventana principal. Al pulsar en este botón, la ventana vuelve a su estado normal.
• WindowInfo.PALETTE Algunas ventanas están diseñadas para poder ser empotradas dentro de otras. Estas ventanas tienen dos modos: modo empotrado y modo paleta (flotante). Cuando están en modo paleta, el contenido se muestra en una ventana independiente, de tipo MODELESSDIALOG. Cuando están en modo empotrado, el contenido está integrado en algún área de otra ventana. El localizador gráfico, por ejemplo, es una herramienta que es capaz de mostrarse en una ventana independiente o bien empotrado en la parte inferior izquierda de una vista. Las ventanas tipo paleta deben implementar la interfaz IWindowTransform.
• Además, existen los dos atributos que ya hemos explicado anteriormente: WindowInfo.MODALDIALOG y WindowInfo.MODELESSDIALOG.

Para crear una ventana modeless redimensionable y maximizable:

WindowInfo windowInfo = new WindowInfo(WindowInfo.MODELESSDIALOG | WindowInfo.RESIZABLE | WindowInfo.MAXIMIZABLE);
return windowInfo;

No es posible utilizar simultáneamente las propiedades MODELESSDIALOG y MODALDIALOG. Además de que no tiene sentido, si lo hacemos obtendremos un error de Andami.

Hasta aquí hemos visto las propiedades que acepta el constructor de la clase WindowInfo, y que determinan el comportamiento de la ventana. Además de esto, existe una serie de métodos que permiten consultar diversas propiedades de la ventana, así como modificarlas:

• public int getX()

Devuelve la coordenada X (en píxeles) del vértice superior izquierdo de la ventana. El origen de coordenadas (punto 0, 0) se sitúa en la parte superior izquierda de la ventana principal, justo debajo de la barra de herramientas.

• public void setX(int x)

Establece la coordenada X (en píxeles) del vértice superior izquierdo de la ventana.

• public int getY()

Devuelve la coordenada Y (en píxeles) del vértice superior izquierdo de la ventana. El origen de coordenadas (punto 0, 0) se sitúa en la parte superior izquierda de la ventana principal, justo debajo de la barra de herramientas.

• public void setY(int y)

Establece la coordenada Y (en píxeles) del vértice superior izquierdo de la ventana.

• public int getNormalX()

Cuando la ventana no está maximizada, obtiene la coordenada X (en píxeles) del vértice superior izquierdo. Cuando está maximizada, devuelve la coordenada X que tendría la ventana si no estuviese maximizada.

• public void setNormalX(int x)

Establece la coordenada X (en píxeles) del vértice superior izquierdo de la ventana cuando la ventana está no-maximizada. Si la ventana está maximizada actualmente, este método no cambia su estado, pero al restaurar la ventana al estado normal la coordenada X será la establecida aquí.

• public int getNormalY()

Cuando la ventana no está maximizada, obtiene la coordenada Y (en píxeles) del vértice superior izquierdo. Cuando está maximizada, devuelve la coordenada Y que tendría la ventana si no estuviese maximizada.

• public void setNormalY(int y)

Establece la coordenada y (en píxeles) del vértice superior izquierdo de la ventana cuando la ventana está no-maximizada. Si la ventana está maximizada actualmente, este método no cambia su estado, pero al restaurar la ventana al estado normal la coordenada X será la establecida aquí.

• public int getWidth()

Devuelve la anchura (en píxeles) de la ventana.

• public void setWidth(int width)

Establece la anchura (en píxeles) de la ventana.

• public int getHeight()

Devuelve la altura (en píxeles) de la ventana.

• public void setHeight(int height)

Establece la altura (en píxeles) de la ventana.

• public int getNormalWidth()

Cuando la ventana no está maximizada, obtiene la anchura (en píxeles) de la ventana. Cuando está maximizada, devuelve la anchura que tendría la ventana si no estuviese maximizada.

• public void setNormalWidth(int width)

Establece la anchura (en píxeles) de la ventana cuando no está minimizada. Si la ventana está maximizada actualmente, este método no cambia su estado, pero al restaurarla al estado normal la ventana tendrá la anchura establecida aquí.

• public int getNormalHeight()

Cuando la ventana no está maximizada, obtiene la altura (en píxeles) de la ventana. Cuando está maximizada, devuelve la altura que tendría la ventana si no estuviese maximizada.

• public void setNormalHeight(int height)

Establece la altura (en píxeles) de la ventana cuando no está minimizada. Si la ventana está maximizada actualmente, este método no cambia su estado, pero al restaurarla al estado normal la ventana tendrá la altura establecida aquí.

• public Rectangle getBounds()

Obtiene la posición y dimensiones (en píxeles) de la ventana.

• public void setBounds(Rectangle bounds)

Establece la posición y dimensiones (en píxeles) de la ventana.

• public Rectangle getNormalBounds()

Cuando la ventana no está maximizada, obtiene la posición y dimensiones (en píxeles) de la ventana. Cuando está maximizada, devuelve la posición y dimensiones que tendría la ventana si no estuviese maximizada.

• public void setBounds(Rectangle bounds)

Establece la posición y dimensiones (en píxeles) de la ventana cuando está no-maximizada. Si la ventana está maximizada actualmente, este método no cambia su estado, pero al restaurarla al estado normal la ventana tendrá la posición y dimensiones establecidas aquí.

• public String getSelectedTool()

Obtiene el actionCommand la herramienta seleccionada asociada a la ventana actual (ver la descripción de <selectable-tool> para conocer el mecanismo de herramientas seleccionables).

• public String getTitle()

Obtiene el título de la ventana.

• public void setTitle(String title)

Establece el título de la ventana.

• public int getId()

Obtiene el identificador de ventana.

• public void setId(int id)

Establece el identificador de ventana.

• public boolean isClosed()

Devuelve cierto (true) si la ventana está cerrada, falso (false) en caso contrario.

• public void setClosed(boolean closed)

Establece si la ventana está abierta o cerrada. La ejecución de este método no cambia el estado de la ventana, use PluginServices.getMDIManager().addWindow(window) y PluginServices.getMDIManager().closeWindow(window) para abrir o cerrar una ventana.

• public boolean isIconfiable()

Devuelve cierto (true) si la ventana es minimizable, falso (false) en caso contrario.

• public boolean isMaximizable()

Devuelve cierto (true) si la ventana es maximizable, falso (false) en caso contrario.

• public void setMaximizable(boolean maximizable)

Establece si la ventana es maximizable o no. La ejecución de este método no cambia el estado de la ventana una vez se ha creado, se debe definir si la ventana es maximizable antes de crearla.

• public boolean isMaximized()

Devuelve cierto (true) si la ventana está maximizada, falso (false) en caso contrario.

• public void setMaximized(boolean maximized)

Maximiza o restaura la ventana dependiendo del parámetro maximized.

• public boolean isModal()

Devuelve cierto (true) si la ventana es modal, falso (false) en caso contrario.

• public boolean isModeless()

Devuelve cierto (true) si la ventana es modeles, falso (false) en caso contrario.

• public boolean isPalette()

Devuelve cierto (true) si la ventana está actualmente en modo paleta (flotante), falso (false) si está empotrada en la ventana correspondiente.

• public void toPalette(boolean b)

Establece si la ventana está en modo paleta o no. La ejecución de este método no cambia el estado de la ventana, simplemente actualiza el objeto WindowInfo. Use la interfaz IWindowTransform para pasar una ventana a modo paleta o restaurarla a modo empotrado.

• public boolean isResizable()

Devuelve cierto (true) si la ventana es redimensionable, falso (false) en caso contrario.

• public boolean isVisible()

Devuelve cierto (true) si la ventana es visible, falso (false) en caso contrario.

• public void setPersistence(boolean persist)

El tamaño, la posición y el estado de las ventanas se almacena en los proyectos de gvSIG, esta información se usa al abrir un proyecto para restaurar las ventanas a su estado anterior. Es posible que no deseemos que se almacene el estado de una ventana concreta (por ejemplo, porque inicialmente deba estar siempre cerrada o en una posición exacta). Este método establece si el estado de esta ventana debe guardarse en los proyectos de gvSIG o debe ser ignorada.

• public boolean checkPersistence()

Devuelve cierto (true) si el estado de esta ventana debe guardarse en los proyectos de gvSIG, falso (false) si debe ser ignorada.

• public XMLEntity getXMLEntity()

Obtiene un árbol XML que almacena las propiedades de este objeto WindowInfo. Es útil para salvar las propiedades de la ventana.

public static WindowInfo createFromXMLEntity(XMLEntity xml)

Método estático que crea un objeto WindowInfo a partir de las propiedades almacenadas en el árbol XML suministrado.

La interfaz MDIManager nos permite interactuar con las ventanas. Es el punto al que debemos dirigirnos para crear ventanas, cerrarlas, cambiarles el tamaño, obtener la ventana activa, obtener la lista de todas las ventanas, etc. Durante la creación de ventanas, se encarga de crear las ventanas con unas propiedades homogéneas (teniendo en cuenta, eso sí, las propiedades que hemos solicitado) y registrarlas en el menú Ventana, entre otras cosas. También se encarga de escuchar los cambios producidos en los objetos WindowInfo para reflejar estos cambios en la ventana real asociada.

Como ya se ha comentado, la gestión de ventanas de Andami es bastante particular porque el programador sólo debe crear un panel con el contenido de la ventana, y MDIManager creará la ventana real. Por esta razón, para cambiar las propiedades de una ventana debemos dirigirnos a MDIManager, que es quien conoce la implementación real de la ventana (frame).

Diagrama que muestra las principales clases relacionadas con el gestor de ventanas

MDIManager posee un amplio rango de métodos para interactuar con las ventanas. La mayoría de ellos requieren una referencia al objeto IWindow que deseamos alterar. Otros, por contra, devuelven una referencia a tal objeto.

Existe un tipo de especial de ventanas de Andami: las ventanas Singleton, ventanas que tienen asociado un modelo. El modelo puede ser cualquier objeto Java que elijamos, y nos sirve para dotar de identidad a la ventana. De esta forma, existirá una única ventana asociada a un modelo, y podremos hacer referencia a la ventana a través del modelo. Si intentamos añadir una ventana Singleton cuyo modelo ya está asociado a otra ventana existente, en vez de crearse una nueva ventana se mandará la ventana existente a primer plano, y obtendremos una referencia a dicha ventana.

La interfaz Singleton cuenta simplemente de un método:

public Object getWindowModel()

Devuelve el modelo de esta ventana Singleton. El modelo debería ser constante en el tiempo para una ventana dada, salvo que realmente queramos cambiar la identidad de la ventana.

La interfaz SingletonWindow extiende la interfaz IWindow, por lo que cualquier ventana que implemente SingletonWindow implementará también IWindow.

La interfaz IWindowListener permite a las ventanas que la implementen registrarse como listener (oyente) de los eventos que suceden sobre sí mismas.

public void windowActivated()

Este método se ejecutará cada vez que se active la ventana.

public void windowClosed()

Este método se ejecutará cuando la ventana se esté cerrando.

Para recibir estos eventos, basta con que las ventanas implementen esta interfaz, Andami lo detectará y les enviará los eventos correspondientes sin necesidad de seguir ningún paso adicional.

Las ventanas tipo PALETTE (ventanas que pueden empotrarse dentro de otras o bien estar en modo flotante o paleta) deben implementar esta interfaz, para pasar correctamente de modo paleta a modo empotrado.

Esta interfaz posee tres métodos, que la ventana debe implementar correctamente de acuerdo a su contexto (ya que cada herramienta adoptará una forma particular en modo empotrado y en modo flotante):

public void toPalette()

Pide a la ventana que se transforme en modo flotante.

public void restore()

Pide a la ventana que se transforme en modo empotrado.

isPalette()

Devuelve cierto si la ventana está en modo paleta (flotante), falso si está en modo empotrado.

Andami proporciona una variedad de servicios a los plugins, casi todos a través de la clase PluginServices. Estos servicios cubren varias tareas que se realizan con frecuencia en cualquier parte de la aplicación, y por tanto conviene ofrecer una forma sencilla de realizarlas.

Cada plugin tiene un objeto PluginServices asociado, que podemos obtener con la llamada:

PluginServices.getPluginSerivices(pluginName)

o bien

PluginServices.getPluginServices(object),

donde object debe corresponderse con algún objeto perteneciente al plugin. Este objeto PluginServices permite acceder a servicios específicos del plugin, como obtención de recursos (imágenes, etc), el nombre del plugin, persistencia de datos, etc. Existen otros servicios no asociados específicamente a cada plugin que son accesibles a través de métodos estáticos de esta misma clase.

Los plugins poseen unos ficheros de traducciones que son leídos durante el inicio de la aplicación. Estos ficheros contienen claves de traducción, y la traducción asociada a cada clave, para cada idioma. De esta forma, los plugins pueden solicitar la traducción de una clave y Andami devolverá la traducción para el idioma que el usuario haya elegido (a través de la configuración del idioma). Usando este mecanismo se puede presentar al usuario una interfaz totalmente traducida a su idioma preferido.

Los ficheros de traducción deben estar situados en el directorio raíz del plugin, y se deben llamar de acuerdo a lo especificado en la etiqueta resourceBundle del config.xml. Los sufijos de idioma de cada nombre de fichero corresponden con el código de dos caracteres ISO 639-1 (en para inglés, fr para francés, etc). El fichero sin sufijo corresponde al idioma Castellano. Siguiendo estas convenciones, las traducciones del plugin son cargadas automáticamente durante la carga de plugins.

Para acceder a estas traducciones desde el plugin, usaremos un código como el siguiente:

PluginServices ps = PluginServices.getPluginServices(this);
ps.getText("clave_de_traduccion");

o bien, a través de un método estático:

PluginServices.getText(this,"clave_de_traduccion");

Hay que tener en cuenta que todos los plugins tienen un espacio de claves de traducción único. Esto significa que si un plugin A posee una traducción como la siguiente en el fichero text.properties:

error_conexion="Error de conexión"

y un plugin B posee una traducción como:

error_conexion="Error conectando a la base de datos"

entonces habrá un conflicto de claves. Si suponemos que el plugin A se carga antes (y por tanto sus traducciones también se cargan antes), cuando el plugin B intente acceder a la traducción:

PluginServices ps = PluginServices.getPluginServices(this);
ps.getText(error_conexion);

obtendría la traducción errónea: "Error de conexión". Por tanto, debemos intentar utilizar claves que describan con precisión el mensaje, para evitar este de error. Si el plugin no va a ser integrado en la distribución principal de gvSIG, podemos usar un prefijo de clave para curarnos en salud:

org.gvsig.MipluginCasero.error_conexion="Error conectando a la base de datos"

El servicio de registro permite mantener un histórico de sucesos de una sesión completa de gvSIG. Los sucesos pueden tener distinta categoría: Información, Avisos, Errores o Información para Depuración. Al registrar algún mensaje en el log, automáticamente se registra también el plugin que genera el mensaje.

Es importante registrar los errores en el log, a fin de poder depurarlos posteriormente. Es frecuente que los usuarios encuentren errores que somos incapaces de reproducir en nuestra máquina, y la única herramienta con la que podemos corregir estos errores es mediante la información registrada en el log. El fichero de log se almacena en el directorio gvSIG dentro del directorio del usuario. En Windows, típicamente está en:

C:\Archivos de programa\Documents and Settings\%USER%\gvSIG\gvSIG.log

y en Linux, está en:

/home/$USER/gvSIG/gvSIG.log

Utilizar el log desde un plugin es muy sencillo:

Logger logger = PluginServices.getLogger();
logger.info("Mensaje a mostrar en el log");

Como ya hemos dicho, existen 4 niveles de severidad:

• depuración (DEBUG), indica que esta información sólo es interesante para depurar (corregir) el programa. En esta severidad podemos mostrar (por ejemplo) los típicos mensajes que verifican que estamos entrando dentro de un if.
• información (INFO), indica que el mensaje es meramente informativo (no contiene ningún error).
• aviso (WARNING), indica que la información mostrada tiene la intención de avisar de algún hecho especial. Debemos mostrar en esta severidad los hechos inusuales o inesperados que puedan ser indicios de error (pero no errores claros).
• error (ERROR), indica que se ha producido un error en la aplicación. Debemos mostrar información relevante para poder detectar el origen del error y permitir subsanarlo (ya sea al usuario o al programador).

Accederemos a estos cuatro niveles usando los correspondientes métodos: debug(), info(), warning() y error().

Si se ha producido una excepción y deseamos incluir en el log la salida del método printStackTrace, podemos hacerlo de forma muy sencilla:

catch (Exception excepcion) {
  logger.error("Mensaje de error", excepcion);
}

Existe un fichero (plugin-persistence.xml) en el que los plugins pueden almacenar información (ejemplos: un plugin de WMS podría almacenar la lista de servidores recientes; un plugin de nomenclátor podría almacenar las últimas búsquedas realizadas). De esta forma, al volver a arrancar gvSIG, los plugins pueden recuperar la información guardada y presentar (por ejemplo) la lista de servidores usados en la última sesión. Cada plugin sólo tiene acceso (de forma directa) a la información que él mismo produce. Debemos aclarar que este fichero es adecuado para guardar pequeñas cantidades de información de texto, pero no es adecuado para guardar otros tipos de información como miniaturas de la cartografía, un listado de nombres de municipios, etc.

El fichero se lee automáticamente durante el inicio de Andami, y se guarda automáticamente al salir de la aplicación. El fichero está en formato XML, que almacena la información con una estructura de árbol. Para poder leer o escribir información en esta estructura, haremos uso del objeto XMLEntity, que representa una subrama del árbol (una subrama puede contener desde un único nodo hasta el árbol completo).

Para obtener la subrama asociada a nuestro plugin, utilizaremos:

XMLEntity entity = PluginServices.getPluginServices(this).getPersistentXML();

Si suponemos que previamente habíamos almacenado una propiedad llamada "last.server", podemos recuperarla usando:

try {
  XMLEntity entity = PluginServices.getPluginServices(this).getPersistentXML();
  String lastServer = entity.getStringProperty("last.server");
}
catch (NotExistInXMLEntity exception) {
  // mostrar el error y tomar alguna acción en respuesta
}

Podemos ver el objeto XMLEntity como una especie de tabla Hash que asocia claves con valores. En el ejemplo anterior, "last.server" es una clave.

Para almacenar una nueva clave:

XMLEntity entity = PluginServices.getPluginServices(this).getPersistentXML();
entity.putProperty("last.server", "http://www.gvsig.org");

Es posible almacenar diversos tipos de objetos en el XMLEntity:

XMLEntity entity = PluginServices.getPluginServices(this).getPersistentXML();
entity.putProperty("last.server", "http://www.gvsig.org");
entity.putProperty("maxConnections", 5);
entity.putProperty("timeout", 3.258);
String[] servers = {"http://www.gvsig.org","www.gvsig.gva.es","www.cit.gva.es"}
entity.putProperty("preferred.servers", servers);
int[] allowedValues = {1,2,5,10};
entity.putProperty("allowed.values", allowedValues);

Y para recuperar estos objetos:

try {
  XMLEntity entity = PluginServices.getPluginServices(this).getPersistentXML();
  String lastServer = entity.getStringProperty("last.server");
  int maxConnections =  entity.getProperty("maxConnections");
  float timeout = entity.getFloatProperty("timeout");
  String[] servers = entity.getStringArrayProperty("preferred.servers");
  int[] allowedValues = entity.getIntArrayProperty("allowed.values");
}
catch (NotExistInXMLEntity exception) {
  // mostrar el error y tomar alguna acción en respuesta
}

Además, podemos anidar los objetos XMLEntity:

XMLEntity entity = PluginServices.getPluginServices(this).getPersistentXML();
XMLEntity hijo = new XMLEntity();
hijo.setName("ColorData");
hijo.putProperty("red", "#ff0000");
hijo.putProperty("green", "#00ff00");
hijo.putProperty("blue", "#0000ff");
hijo.putProperty("black", "#000000");
hijo.putProperty("white", "#ffffff");
entity.addChild(hijo);

Y para recuperar el XMLEntity anidado:

XMLEntity child=null, tmpchild; 
for (int i=entity.getChildrenCount()-1; i>=0; i--) {
  tmpchild = entity.getChild(i);
  if (child.getName().equals("ColorData")) {
    child = tmpchild;
    break;
  }
}

if (child!=null) {
  try {
    String rojo = child.getStringProperty("red");
    String verde = child.getStringProperty("green");
    String azul = child.getStringProperty("blue");
    String negro = child.getStringProperty("black");
    String blanco = child.getStringProperty("white");
  }
  catch (NotExistInXMLEntity exception) {
    // mostrar el error y tomar alguna acción en respuesta
  }
}

Andami facilita la creación de tareas en segundo plano, permitiendo además que estas tareas sean cancelables (interrumpibles). Si deseamos realizar un procesamiento prolongado, conviene lanzarlo en un hilo separado (proceso en segundo plano), para no bloquear la interfaz gráfica. Un típico ejemplo de tarea a lanzar en segundo plano sería la exportación de una capa a un fichero. Se presentará un diálogo al usuario con el progreso de la tarea, y un botón que permita la cancelación del proceso.

Para crear la tarea usaremos el método:

• public static void cancelableBackgroundExecution IMonitorableTask task)

Para crear cómodamente una tarea en segundo plano, existe la clase abstracta AbstractMonitorableTask que implementa IMonitorableTask y que podemos extender anónimamente para crear nuestra tarea:

PluginServices.cancelableBackgroundExecution(new AbstractMonitorableTask() {
  public void run() {
    for (int i=0; i<100001; i++) {
      System.out.println("hilo mundo "+i);
    }
  }
});

Simplemente con esto, la parte que está dentro del método run() se ejecutará en un nuevo hilo.

Si queremos mostrar un diálogo de progreso y dar la posibilidad de cancelar la operación, podemos añadir algunas líneas:

PluginServices.cancelableBackgroundExecution(new AbstractMonitorableTask() {
  public void run() {
    setNote(PluginServices.getText(this, "Exportar_fichero"));
    setInitialStep(0);
    setFinalStep(100000);
    for (int i=0; i<100001; i++) {
      if (!isCanceled()){
        System.out.println("hilo mundo"+i);
        setCurrentStep(i);
      }
      else {
        return;
      }
    }
  }
});

El diálogo desaparecerá automáticamente al llegar al final step (en este caso 100.000), y no desaparecerá hasta que llegue al final step aunque el nuevo hilo ya haya finalizado.

Si tenemos alguna necesidad especial que AbstractMonitorableTask no cubre, existen varias opciones:

• Extender AbstractMonitorableTask de forma no anónima, reescribiendo los métodos que necesitemos y el constructor.
• Extender DefaultCancellableMonitorable en una nueva clase que a la vez implemente IMonitorableTask, reescribiendo los métodos que necesitemos y el constructor.
• Crearnos una clase totalmente nueva que simplemente implemente IMonitorableTask e incorpore toda la funcionalidad que necesitemos.

El siguiente diagrama muestra toda la jerarquía de clases implicada en la creación de tareas en segundo plano, para que veamos con más claridad el significado de extender de una u otra clase:

Al extender AbstractMonitorableTask de forma anónima y pedirle que muestre el diálogo de progreso, nos muestra un diálogo de progreso indeterminado, es decir, la barra no avanza desde el inicio hasta el fin, si no que oscila a izquierda y derecha continuamente hasta que acaba la tarea. Ahora vamos a mostrar un ejemplo en el que extenderemos AbstractMonitorableTask de forma no anónima a fin de mostrar una barra de progreso determinada:

public class BackgroundTask extends AbstractMonitorableTask {
  public BackgroundTask() {
    setDeterminatedProcess(true);
    setNote(PluginServices.getText(this, "Exportar_fichero"));
    setStatusMessage(PluginServices.getText(this, "Exportando..."));
    setInitialStep(0);
    setFinalStep(100000);
  }   
  public void run() {
    for (int i=0; i<100001; i++) {
      if (!isCanceled()){
        System.out.println("hilo hilero"+i);
        setCurrentStep(i);

      }
      else {
        return;
      }
    }
  }
}

y haremos uso de ella de la siguiente forma:

PluginServices.cancelableBackgroundExecution(new BackgroundTask());

Andami ofrece facilidades para crear ficheros temporales, que son eliminados automáticamente al salir de gvSIG (siempre que gvSIG finalice correctamente). Por una parte, si suministramos un nombre y unos datos, Andami creará el fichero temporal con el contenido proporcionado. Por otra parte, podemos solicitar la ruta del directorio de ficheros temporales y crear en él los ficheros que necesitemos. En ambos casos, los ficheros se eliminan automáticamente al salir de gvSIG. Para acceder a este servicio no usamos PluginServices sino una clase llamada Utilities.

public static void createTemp(String fileName, String data)throws IOException

Crea un fichero llamado fileName, escribe en él el contenido de data y finalmente cierra el fichero. Al salir de gvSIG, el fichero se cerrará automáticamente.

public static String createTempDirectory()

Crea el directorio para ficheros temporales, si no existe, y devuelve la ruta al mismo. Todos los ficheros que creemos en este directorio se borrarán automáticamente al salir de gvSIG.

Es frecuente que los plugins incluyan diversos recursos (normalmente imágenes, tal vez algún fichero XML, cartografía en algún plugin especial...). A la hora de acceder a ellos, no debemos usar rutas absolutas ni tampoco rutas relativas que incluyan el nombre del plugin, ya que eso es poco portable (un cambio en el nombre del plugin provocaría que el código dejase de funcionar). Lo correcto es acceder a ellos usando una ruta relativa al directorio raíz del plugin.

Cada plugin tiene asociado un PluginClassLoader que es capaz de cargar recursos usando rutas relativas al directorio raíz del plugin. Para acceder a dicho ClassLoader, tenemos varias opciones:

PluginServices ps = PluginServices.getPluginServices(this);
PluginClassLoader loader = ps.getClassLoader();

o bien

ClassLoader loader = this.getClass().getClassLoader();

Una vez tengamos el ClassLoader, usaremos el método getResource() para obtener una URL con la ruta absoluta del recurso. Por ejemplo, supongamos que queremos cargar una imagen llamada close.png que está en el subdirectorio images de nuestro plugin. Es decir, la imagen está en gvSIG/extensiones/org.gvsig.miplugin/images/close.png y por tanto la ruta relativa al directorio raíz del plugin sería images/close.png. Para acceder a ella usaríamos:

URL imageURL = loader.getResource("images/close.png");
if (imageURL!=null)
  ImageIcon icon = new ImageIcon(imageURL);

Andami ofrece métodos para obtener texto del portapapeles, o depositar texto en él:

public static void putInClipboard(String data)

Deposita en el portapapeles la cadena de texto contenida en data.

public static String getFromClipboard()

Obtiene el contenido de texto del portapapeles si existe alguno, o null en caso contrario.

Estos métodos están pensados para agilizar el acceso cuando requiramos manipulaciones simples del portapapeles, y consituyen simples atajos para los métodos estándar de Java . Si necesitamos manipular otros tipos de datos (o hacer uso de características avanzadas como la selección de sistema), debemos echar un vistazo a las clases ClipBoard, Transferable y DataFlavour de Java y a los métodos Toolkit.getDefaultToolkit().getSystemClipboard() y Toolkit.getDefaultToolkit().getSystemSelection().

Principales tipos de capas

En este apartado se describe brevemente los principales tipos de capas que, heredando de FLayer, FLyrDefault, o, FLayers, se implementan en la librería libFMap o en algún otro proyecto de gvSIG . Pulsa aquí para visualizar el diagrama 2 en grande.

Diagrama 2: Diagrama simplificado que muestra los principales tipos de capas declaradas en la librería libFMap u otro proyecto de gvSIG.

Resumen

A día de hoy, las Infraestructuras de Datos Espaciales (IDEs) [1] son consideradas el futuro para la búsqueda y el acceso a los recursos cartográficos, una de las pruebas es la directiva europea INSPIRE [2] por la que se establece un marco legal para la creación de una IDE europea. Esta extensión de publicación se trata del desarrollo hecho conjuntamente por la Consellería de Infraestructuras y Transportes de la Generalitat Valenciana y la empresa IVER T.I para la creación de una herramienta capaz de publicar datos cartográficos en una IDE utilizando gvSIG [3] como software base.

gvSIG es un GIS de escritorio, capaz de visualizar datos vectoriales en formatos estándar GIS y CAD, ráster y bases de datos con información espacial. Puede imprimir mapas, editar tanto ficheros de CAD, GIS así como bases de datos geoespaciales además de actuar como cliente avanzado de Infraestructuras de Datos Espaciales. El desarrollo software del que hablaremos en este artículo es un módulo que hace de gvSIG el centro de publicación de cartografía en internet mediante servicios estándar OGC[4] WMS (Web Mapping Service)[5], WFS (Web Feature Service)[6] y WCS (Web Coverage Services)[7], así como su notificación a servicios de catálogo accesibles mediante z39.50 o CSW (Catalogue Services Web)[8].

Este módulo (extensión de publicación de gvSIG) genera de manera transparente para el usuario los ficheros de configuración que utilizan Mapserver [9], Geoserver [10], Deegree[11] o Geonetwork[12], las aplicaciones web más comunes para proporcionar los mencionados servicios. De esta forma, sin un conocimiento específico de estas aplicaciones, el usuario de gvSIG es capaz de publicar en internet, con extrema sencillez, la cartografía que genera.

Introducción

Las IDEs son un conjunto de tecnologías y prácticas institucionales que permiten a los usuarios buscar, obtener y compartir información geoespacial. Hasta ahora el método clásico de acceso a dicha información era a través de “ficheros locales” que seguían cierto formato como pueden ser shapefiles, dgn, geotiff, etc. Con este nuevo paradigma de acceso a la información, el usuario “se conecta” a los proveedores distribuidos de información que mantienen los datos, evitando la duplicidad y el acceso a datos obsoletos o incorrectos, entre otras ventajas. Aunque ya existían bases de datos y protocolos para el acceso a recursos a través de la red, la fuerza del paradigma IDE está en el hecho de definirse sobre estándares y mecanismos de interoperabilidad entre sistemas. Los estándares permiten crear sistemas interoperables, es decir, capaces de comunicarse entre sí ya que “hablan el mismo idioma” y siguen las mismas reglas, por tanto podremos crear nodos de información geográfica que pueden comunicarse con otros nodos formando una red de sistemas proveedores de información. Esto permitirá la creación de IDEs en distintos ámbitos, por ejemplo a nivel institucional, local, regional, nacional y global, que al estar interconectadas entre sí, facilitará a los usuarios el acceso a cualquier recurso cartográfico publicado. Se consigue de esta manera un sistema escalable de acceso estándar a gran cantidad de información.

Algunos estándares OGC:

Estos estándares, definidos es su mayoría por el Open Geospatial Consortium (OGC) (ver tabla anterior), son implementados en su parte servidor por productos como Mapserver, Geoserver, Deegree y Geonetwork, entre otros. Estas implementaciones forman parte fundamental (junto a las aplicaciones cliente) de la tecnología que forma una IDE. El modulo de gvSIG que aquí se presenta trata de configurar o poner en funcionamiento estos servidores de una forma sencilla para el usuario. Una de las consecuencias de las especificaciones estándar es la posibilidad de desarrollar la tecnología subyacente a las IDEs por parte de varios proveedores, es decir, tanto Mapserver como Geoserver pueden implementar la especificación del estándar WMS, lo que permite a los usuarios disponer de varias alternativas. Si además estos productos son de software libre el avance tecnológico no está limitado por las empresas sino que lo está por las demandas de los usuarios y la evolución de los estándares.

Objetivos

El principal objetivo de esta extensión es la de poder publicar en un servicio OGC estándar la información cartográfica que un usuario está visualizando en una vista de gvSIG. Para ello, esta extensión tendrá que generar los ficheros de configuración necesarios correspondientes al servidor y servicio seleccionado.

Algunas consecuencias

• Promover el desarrollo de las IDE.

El hecho de que existan varias alternativas a la hora de elegir el software que implementan las especificaciones, implica el conocimiento de la tecnología de cada producto, por ejemplo, si decido utilizar Mapserver como servidor WMS, Geoserver como WFS, Deegree como WFS-G y Geonetwork como CSW2, tendré que emplear distintas herramientas para la configuración y puesta en funcionamiento de cada uno de los servicios basándose en un conocimiento técnico de cada uno ellos. Este escenario hace difícil, incluso para un usuario con conocimientos de GIS, poder publicar su cartografía. Uno de los objetivos de la extensión de publicación es la de fomentar la implantación de IDEs poniendo a disposición de la comunidad de usuarios un herramienta integral para la publicación de sus mapas, metadatos, coberturas y todo tipo de información susceptible de ser accedida mediante un servicio estándar. Si un usuario GIS está acostumbrado al uso de gvSIG, el publicar sus datos será muy sencillo. Por otra parte la facilidad de uso del programa hace que, sin grandes conocimientos de GIS, sea factible disponer de un servicio de mapas, de catálogo, etc.

• Uso eficiente de los recursos.

Con una herramienta integral para la publicación de información en los servidores de una IDE, el recurso humano con perfil de informático es, entre otras muchas cosas, el responsable de instalar y mantener el software de los servidores, bases de datos , etc, mientras que el recurso con perfil GIS es el encargado de alimentar de datos esa infraestructura. En esta situación el usuario GIS delega la responsabilidad de conocer tecnología específica de sistemas de información y se centra en la componente geográfica. Por otra parte estamos ahorramos tiempo ya que la generación de la configuración de los servidores es casi automática.

Referencias

• [1] Spatial Data Infraestructure Cookbook v2.0 http://www.gsdi.org/docs2004/Cookbook/cookbookV2.0.pdf
• [2] Proposal for a directive of the European Parliament and of the council establishing an infrastructure for spatial information in the Community (INSPIRE) http://www.ec-gis.org/inspire/proposal/EN.pdf
• [3] http://www.gvsig.gva.es
• [4] http://www.opengeospatial.org/
• [5] Web Map Service Implementation Specification http://www.opengeospatial.org/standards/wms
• [6] Web Feature Service Implementation Specification http://www.opengeospatial.org/standards/wfs
• [7] Web Coverage Service Implementation Specification http://www.opengeospatial.org/standards/wcs
• [8] Catalogue Service Implementation Specification http://www.opengeospatial.org/standards/cat
• [9] http://mapserver.gis.umn.edu/
• [10] http://docs.codehaus.org/display/GEOS/Home
• [11] http://www.deegree.org/
• [12] http://geonetwork-opensource.org/

• Recurso cartográfico: información sobre una entidad georeferrenciada . Por ejemplo un mapa, una feature, una cobertura, un metadato,etc.
• Service: protocolo de comunicación en la arquitectura cliente-servidor.
• Server: producto software que implementa la especificación de un servicio.
• Publicación: generación de los recursos necesarios (ficheros de configuración) para que funcione correctamente un servidor.
• Feature: Entidad cartográfica vectorial como un punto, línea o polígono.
• Topónimo: nombre que identifica una feature.
• Metadato: Información asociada a un recurso cartográfico.
• WMS: Servicio de mapas. El cliente se comunica con el servidor para obtener "fotografías" de la cartografía.
• WFS: Servicio de features. El cliente se comunica con el servidor para obtener cartografía vectorial.
• WCS: Servicio de cobeberturas. El cliente se comunica con el servidor para obtener cartografía en forma de coberturas ráster.
• WFS-G: Servicio de nomenclátor. Perfil (caso de uso específico) del protocolo WFS en el que el cliente obtiene un feature a partir de un topónimo.
• CS-W: Servicio de catálogo. El cliente puede realizar búsquedas sobre infromación cartográfica en un catálogo de metadatos.
• SLD: Descriptor de estilos de capas. Especificación de cómo debe definirse la leyenda y simbología de una capa WMS.
• Mapfile: Fichero de configuración de Mapserver.
• SRS: Sistema de referencia espacial. Sistema de coordenadas de cualquier georreferenciación.
• Leyenda
• Símbolo

Convenciones UML

<<analysis subsystem>>

Esteroripo utilizado para especificar subsistemas de análisis. Estos subsistemas representan la arquitectura del sistema a alto nivel. Dicho subsistema agrupa clases de análisis.

IMPORTANTE: Un subsistema de análisis NO ES UN PAQUETE JAVA.

<<boundary>>

Clases del análisis que representan la frontera de un subsistema. Cuando hablemos de subsistemas de interfaz de usuario representan las ventanas y controles con los que trabaja el usuario. En el caso de ser un otro tipo de subsistema distinto, se trata de los interfaces públicos.

IMPORTANTE: Una clase del análisis NO ES UNA CLASE JAVA.

<<control>>

Clases del análisis que encapsulan la funcionalidad del sistema. En subsistemas de interfaz de usuario recogen e interpretan los eventos del usuario. En otro tipo de subsistemas se encargan de realizar cálculos y colaboraciones entre objetos del modelo.

IMPORTANTE: Una clase del análisis NO ES UNA CLASE JAVA.

<<entity>>

Clases del análisis que representan el modelo de la aplicación.

IMPORTANTE: Una clase del análisis NO ES UNA CLASE JAVA.

La funcionalidad de esta extensión la podemos dividir en unos caso de uso de alto nivel y unos casos de uso específicos asociados a cada tipo de servidor concreto.

Casos de uso de alto nivel

La funcionalidad a más alto nivel que espera el usuario de esta extensión es la de publicar la vista activa de gvSIG en un servidor para poder acceder a los recursos cartográficos de forma remota. En cuanto a publicar una vista nos referimos a generar los ficheros de configuración necesarios para que un servidor pueda suministrar la misma información (imágenes, coberturas, features, ...)que el usuario está visualizando en la vista de gvSIG. La vista se podrá publicar en distintos servidores como Mapserver o Geoserver.

Diagrama de casos de uso de alto nivel

En términos generales, publicar una vista consistirá en primer lugar en especificar el servidor que queremos configurar. Esto básicamente es indicar la URL del servidor y marca , por ejemplo, Geoserver en

http://localhost/geoserver.

Tras ello, deberemos especificar los parámetros específicos del servidor seleccionado, por ejemplo, aquí tendremos que especificar los servicios que queremos configurar ya que cada tipo de servidor implementa unos servicios específicos. En esta actividad también se tendrá que indicar los parámetros para cada servidor en concreto, por ejemplo, en Mapserver tendremos que notificar al sistema que el directorio temporal que debe emplear. La siguiente actividad será especificar los parámetros específicos de cada uno de los servicios y de los recursos remotos que queremos generar. Por ejemplo, si queremos configurar un servicio WMS, tendremos que establecer el título, resumen, palabras clave, etc, del servicio y de cada una de las capas. Finalmente se publicará la vista, es decir, se generará los ficheros de configuración del servidor seleccionado.

Por otra parte, la extensión debe ser extensible en cuanto a funcionalidad. Por ejemplo, inicialmente publicaremos servicios WMS y WCS en Mapserver pero puede que en un futuro lo haga también en WFS, por ello cada servidor tiene unos puntos de extensión asociados como se muestra a continuación.

Casos de uso asociados a Mapserver

Diagrama de casos de uso de asociados a Mapserver

Casos de uso asociados a Geoserver

Diagrama de casos de uso de asociados a Geoserver

La arquitectura del sistema se puede dividir en cuatro bloques de alto nivel. El interfaz de usuario, la librería servidores, un bloque horizontal que proporciona información sobre los recursos que se quieren publicar y finalmente los plugins, que en esta primera versión será el de Mapserver y Geoserver.

Subsistemas de análisis del framework de publicación.

gui

Este bloque representa el interfaz de usuario de la aplicación. Tiene la responsabilidad de obtener la información que aporta el usuario y que es necesaria para realizar una publicación.

modelServers

Este subsistema representa el modelo de servidores. Tiene la responsabilidad de generar los ficheros de configuración necesarios para el funcionamiento del servidor correspondiente.

infoProject

Este último bloque será empleado por las librerías de los servidores para obtener información sobre los recursos que se desean publicar, en concreto, sobre el proyecto que se quiere publicar, es decir, capas, leyenda, simbología, etc. Esta información provendrá del proyecto y vista activa de gvSIG.

plugins

Este susbsistema representa la parte del sistema que extenderá el framework compuesto por los tres subsistemas anteriores para poder hacer la publicación en un servidor concreto. En esta primera versión se realizará un plugin para Mapserver y otro para Geoserver.

Las pruebas que se describen a continuación hacen referencia a los test automáticos que intentan validar la correcta implementación de la funcionalidad de la extensión, es decir, la correcta generación de los ficheros de configuración. Por tanto, habrá un caso de prueba por cada uno de los casos de uso de alto nivel que describíamos anteriormente. Con estas pruebas conseguiremos validar la correcta integración de los distintos subsistemas, exceptuando el gui que llevará un tratamiento especial en cuanto a pruebas automáticas.

Cuando entremos en detalle en cada subsistema o bloque, especificaremos con más detalle las pruebas asociadas a cada bloque en particular. En estos test de más bajo nivel se intentará validar la funcionalidad específica de cada subsistema.

En esta primera versión de la extensión de publicación, se va a desarrollar el plugin para Mapserver (WMS y WCS) y el plugin para Geoserver (WFS). Por tanto, y viendo los casos de uso de alto nivel, los casos de prueba son los siguientes:

Caso de prueba “publish Mapserver WMS” (test_publishMapserverWMS)

En este conjunto de pruebas se deberá considerar los siguientes aspectos relacionados con los requisitos:

1. Publicación de distintas fuentes de datos tales como shapefiles, postGIS y ráster ECW y Geotiff.
2. Publicación de la leyenda, valores únicos e intervalos.
3. Publicación de la simbología para puntos, líneas y polígonos
4. Publicación de capas anidadas.

Por tanto se espera que tras la ejecución de este test se ha creado un fichero mapfile y otro sysbolsfile con la configuración de un servicio WMS de Mapserver y que cumple con los puntos mencionados anteriormente.

Caso de prueba “publish Mapserver WCS” (test_publishMapserverWCS)

Aquí nos centraremos en comprobar la correcta configuración del mapfile para que puedan obtenerse coberturas en formato Geotiff.

Caso de prueba "publish all services in Mapserver" (test_publishMapserver)

Puesto que Mapserver puede definir en el mismo fichero Mapfile varios servicios, en este test se espera obtener un fichero mapfile" que contenga la configuración básica de un servicio WMS y otro WCS. Para ello se puede publicar una vista con un shapefile con leyenda simple y un raster.

Caso de prueba “publish Geoserver WFS” (test_publishGeoserverWFS)

En este caso nos centraremos en la correcta generación de los ficheros de configuración de Geoserver, considerando todas las fuentes de datos que se definen en los requisitos, shapefiles y postGIS. Con este test se pretende obtener un fichero services.xml, catalog.xml y un fichero info.xml por cada capa wfs.

TODO: Clases de apoyo para los test

El modelo de servidores es el núcleo principal de la extensión ya que es responsabilidad suya el generar los ficheros de configuración. Para generar estos ficheros, empleará la información proveniente del subsistema infoProject más la que le proporciona el usuario a través del subsistema gui.

Las entidades más importantes son el servidor (Mapserver, Geoserver, ...) que puede ofrecer varios servicios (WMS, WFS, WCS, ...). Además, un servicio está compuesto por una serie de recursos remotos a los cuales accederá el cliente , estos recursos remotos son, por ejemplo, una capa WMS, una cobertura WCS, una feature WFS, un metadato CS-W, ...

Un recurso remoto puede a su vez contener más recursos remotos. Un ejemplo son los recursos remotos que ofrece un servicio WMS en los que una capa WMS puede ser el conjunto de varias capas.

Por otra parte, tenemos entidades OGC que tienen título, nombre y descripción. La intención es poder reutilizar esta información para realizar publicaciones en distintos servidores.

Clases de análisis del subsistema modelServers

La funcionalidad que se espera de este subsistema es la de generar la publicación sin necesidad de un gui.

Se puede decir que el caso de uso de alto nivel publicar vista incluye los casos de uso que describimos a continuación.

El siguiente diagrama de casos de uso especifica la funcionalidad que debe cumplir cada una de las librerías de servidor:

Diagrama de casos de uso del subsistema libServers

El cliente de la librería, ya sea un gui u otro programa, en primer lugar especificará los parámetros del servidor incluyendo los servicios que quiere configurar. En segundo lugar tendrá que configurar cada uno de los servicios y los recursos asociados a él. Una vez el sistema tiene toda la información necesaria para la publicación ya se puede invocar la generación de la configuración.

Para cualquier librería que extienda el framework, se deberán de crear los siguientes test automáticos:

Caso de prueba "set server parameters" (test_set<server>Param)

Caso de prueba "set service parameters" (test_set<service>Param)

Caso de prueba "set resources parameters" (test_set<resource>Param)

Caso de prueba "make configuration" (test_make<server>Conf)

TODO: descripción de cada una de las pruebas

Clases de diseño del subsistema modelServers

Publication

Esta clase representa la publicación que se puede realizar en un servidor.

Operaciones

setServer(s:Server) Inicializamos la publicación con un servidor

getServer():Server Obtenemos el servidor de la publicación

Excepciones

TODO

Server

Representa un servidor abstracto. Un servidor puede ofrecer varios servicios.

Operaciones

Server() Constructor por defecto, inicializa el servidor con todos los servicios que se han registrado en él.

Server(service:String) Constructor en el que sólo se inicializa con el servicio especificado

getType():String Devuelve una cadena que identifica el tipo de servidor. Por ejemplo, "mapserver".

toString():String Sobreescribimos el método "toString" para obtener el nombre del servidor.

initialize(view:IViewInfo) Inicializamos el servidor con la información de una vista. Para cada servicio invocamos su metodo initialize()

postInitialize() Una vez inicializado el servidor este método comprueba que cada recurso remoto de sus servicios es compatible con el servidor. Para cada servicio invoca su metodo postInitialize().

addService(service:String) Añadimos el servicio a partir del nombre del servicio.

getService(service:String):Service Obtenemos un servicio del servidor a partir del nombre del servicio.

getService(position:int):Service Obtenemos un servicio del servidor a partir de un número que indica el orden en que se introdujo.

getServicesCount():int Obtenemos el número de servicios que tiene actualmente el servidor.

publish() Método abstracto para generar la publicación, es decir, los ficheros de configuración. Llama a los métodos "publish()" de todos sus servicios. Cualquier servidor heredado deberá sobrescribir este método para realizar las operaciones pertinentes, finalmente llamará al método del padre super.publish() para que se realice la publiación de los servicios.

Excepciones

TODO

Service

Clase que representa un servicio abstracto. Una servicio ofrece varios recursos remotos accesibles por un cliente de dicho servicio.

Operaciones

getType():String Devuelve una cadena que identifica el tipo de servicio. Por ejemplo, "mapserver_wms".

toString():String Sobreescribimos el método "toString" para obtener el nombre del servicio.

initialize(view:IViewInfo) Inicializamos el servicio con la información de una vista. Para cada capa de la vista creamos un recurso remoto.

postInitialize() Una vez inicializado el servicio este método comprueba que cada uno de sus servicios remotos es compatible con el servidor y el servicio.

getRemoteResource(position:int):RemoteResource Obtenemos un recurso remoto del servicio a partir de un número que indica el orden en que se introdujo.

getRemoteResourcesCount():int Obtenemos el número de recursos remotos que tiene actualmente el servicio.

publish() Método abstracto para generar la publicación, es decir, los ficheros de configuración. Llama a los métodos "publish()" de todos sus recursos remotos.

Excepciones

TODO

RemoteResource

Operaciones

getType():String Devuelve una cadena que identifica el tipo de recurso remoto. Por ejemplo, "mapserver_wms_layer".

toString():String Sobreescribimos el método "toString" para obtener el nombre del recurso remoto.

initialize(view:ILayerInfo) Inicializamos el recurso con la información de una capa. En el caso de capas anidadas creamos una recursos remoto por cada capa hija.

postInitialize() Comprobamos que todos sus recursos remotos hijos son compatibles con el servidor y el servicio.

getRemoteResource(position:int):RemoteResource Obtenemos un recurso remoto hijo a partir de un número que indica el orden en que se introdujo.

getRemoteResourcesCount():int Obtenemos el número de recursos remotos hijos.

publish() Método abstracto para generar la publicación, es decir, los ficheros de configuración. Llama a los métodos "publish()" de todos sus recursos remotos hijos.

Excepciones

TODO

ServerRegister

Clase encargada de registrar los servidores disponibles para la extensión. Cada plugin de servidor deberá registrarse en este registro.

Operations

addServer(key:String, clase:Class) Registramos un nuevo servidor en la extensión a partir de una cadena que lo identifica (key).

getServerNames():Set Devuelve los nombres (keys) de todos los servidores registrados.

getInstance(key:String) Crea una instancia del servidor especificado por "key".

Excepciones

TODO

ServiceRegister

Clase encargada de registrar los servicios disponibles para la extensión. Cada plugin de servidor deberá registrar sus servicios en este registro.

Operations

addService(key_server:String, key_service:String, clase:Class) Registramos un nuevo servicio correspondiente a un servidor a partir de una cadena que identifica el servidor (key_server) y al servicio (key_service).

getServiceNames(key_server:String):Set Devuelve los nombres (keys) de todos los servicios registrados para un servidor.

getInstance(key_server:String, key_service:String) Crea una instancia del servicio especificado por "key_service" correspondiente al servidor "key_server".

Excepciones

TODO

RemoteResourceRegister

Clase encargada de registrar los recursos remotos correspondientes a un servicio concreto. Cada plugin de servidor deberá registrar sus recursos remotos en este registro.

Operations

addRemoteResource(key_service:String, key_remoteResource:String, clase:Class) Registramos un nuevo recurso remoto asociado a un servicio.

getRemoteResourcesNames(key_service:String):Set Devuelve los nombres (keys) de todos los recursos remotos asociados a un servicio.

getInstance(key_service:String, key_remoteResource) Crea una instancia del recurso remoto especificado por "key_remoteResource" asociado al servicio identificado por la clave "key_service".

Excepciones

TODO

El principal objetivo de este subsistema es el de proporcionar un API para obtener información asociada a un proyecto, una vista, capas, fuentes de datos, leyendas, simbología o etiquetado. En la arquitectura de la extensión, se situaría como un servicio horizontal que proporciona de forma automática toda la información relevante para la publicación. Por ejemplo, si para generar la configuración de un servicio WMS necesitamos la ruta absoluta de un shapefile, habrá que consultar la parte correspondiente a fuentes de datos de este subsistema.

Como podemos ver en la siguiente figura, tenemos información sobre un proyecto y una vista. A su vez, una vista tiene información sobre un conjunto de capas que tienen información sobre su leyenda, la fuente de datos de la que proviene y sobre el etiquetado. Además una leyenda tiene la información referente a la simbología.

Clases de análisis infoProject

La funcionalidad que se espera de este subsistema es la de consultar información sobre los siguientes elementos:

• Proyecto: nombre y propietario.
• Vista: nombre, fecha de creación, propietario, sistema de coordenadas, caja de delimitación y capas.
• Capa: nombre, título, mínima y máxima escala, transparencia, caja de delimitación, fuente de datos, leyenda, etiquetado.
• Leyenda: En función del tipo de leyenda tendremos una información relevante.
  • Leyenda simple: símbolo
  • Leyenda de valores únicos: los símbolos de cada de uno de los valores únicos
  • Leyenda de intervalos: los símbolos de cada intervalo.
• Simbología: Estos son los tipos de símbolos de los que podemos extraer información.
  • Símbolo para líneas: color, grosor, unidades del grosor, patrón de discontinuidad, transparencia.
  • Símbolo para polígonos: color, patrón de relleno, símbolo de la línea exterior.
  • Símbolo para puntos: color, tamaño, unidades del tamaño, gráfico externo o figura conocida.
• Fuentes de datos: Se disponen de las siguientes fuentes de datos:
  • Vectoriales: ruta al fichero, tipo de geometrías, descripción de la tabla de atributos, sistema de coordenadas, caja de delimitación. En el caso de ser un fichero tendremos la ruta a él y en el caso de ser una tabla de base de datos tendremos los parámetros de conexión o claúsula where.
  • Raster: ruta al fichero, número de bandas, descripción de las bandas, resolución, caja de delimitación, sistema de coordenadas.
• Etiquetado. De momento sólo dispondremos del tipo de fuente, el color, el campo del etiquetado, el campo de la rotación, el campo del tamaño o un tamaño fijo en metros o píxeles.

Esta consulta de información se puede dividir en los siguientes casos de uso:

Casos de uso de infoServices

De la misma forma que otros subsistemas, las pruebas automáticas que deberán hacerse en este subsistema vendrán definidas por los casos de uso o funcionalidad esperada de él. De esta forma, tendremos los siguientes casos de prueba:

Caso de prueba "query project" (test_queryProject)

Caso de prueba "query view" (test_queryView)

Caso de prueba "query layer" (test_queryLayer)

Caso de prueba "query data source" (test_queryDataSource)

Caso de prueba "query legend" (test_queryLegend)

Caso de prueba "query symbol" (test_querySymbol)

Caso de prueba "query labeling" (test_queryLabeling)

TODO: Detalles de cada prueba

El interfaz gráfico de la extensión de publicación está compuesto por una ventana principal (MainWindow) y un controlador principal (MainController) encargado de dirigir la publicación.

Esta ventana principal contendrá una vista de un elemento de la publicación (PublishView), esto es, un servidor, una publicación entera con sus servidores, etc. Esta vista de publicación será propia de cada uno de los servidores ya que cada servidor puede tener distintos parámetros y acciones sobre sus vistas.

Para obtener estas vistas, cada servidor concreto tendrá que registrar sus controlador (PublishController) que a parte de obtener dichas vistas específicas, se encargará de recoger los eventos que ocurran en ellas. Nótese cómo este controlador será el que más relación tiene con el modelo (los servidores, servicios y remote resources). La idea es, por tanto, que el controlador principal obtenga el controlador específico de un servidor que le aportará los paneles o vistas concretas para esa implementación.

Por otra parte, y como puede verse en diagrama, tendremos una ventana para seleccionar un nuevo servidor (NewServerWindow) con su correspondiente controlador (NewServerWindowController) que recibirá los eventos del usuario. Este aparece al ejecutar la extensión con la intención de seleccionar el servidor.

Clases de análisis del subsistema gui

También se creará un controlador y una vista por defecto de la publicación. Esta vista estará compuesta por una vista de la publicación en forma de árbol y una vista que muestra los parámetros de los elementos seleccionados en el árbol. La idea es que este controlador y vista por defecto la puedan reutilizar los servidores que quieren mostrar los paneles navegando por un árbol.

Clases de análisis del controlador por defecto

Con la información que aporta infoProject más la que aporta el usuario para el servidor específico, el sistema ya es capaz de generar la configuración correspondiente.

La extensión de publicación cuando arranca obtiene el controlador (IPublishController) del servidor seleccionado y que previamente registró en el registro de controladores (ControllersRegister). De este controlador obtiene una vista de publicación (IPublishView) que mostrará en la ventana principal. Previamente la extensión de publicación (realmente el controlador principal de extPublish MainController) ha obtenido una publicación desde la persistencia que se la pasa al controlador del servidor para que inicialice la vista con los elementos correspondientes. Cuando el usuario pulse el botón "publicar" de la ventana principal (MainWindow), el controlador principal obtendrá el modelo modificado por el usuario para invocar su método publish().

Clases de diseño del subsistema gui

IPublishController

Interfaz que debe implementar cualquier controlador de servidor. La responsabilidades de un controlador son las de crear una vista del modelo (de Publication) y la de recibir los eventos del usuario realizados en la vista.

Operaciones

getModel():Object Obtenemos el modelo que controla y que ha sido modificado por el usuario.

setModel(model:Object) Pasamos el modelo para que lo muestre en su vista

getView():PublishView Obtenemos la vista asociada al controlador NOTA:Quizás sea mejor que devuelva un IPublishView

IPublishView

Interfaz que debe implementar cualquier vista de un modelo (publication,server, service, remoteResource). Las responsabilidades de una vista de publicación son las de mostrar al usuario un estado del modelo.

Operaciones

getModel():Object Obtenemos el modelo que muestra dicha vista.

setModel(model:Object) Pasamos el modelo para que lo muestre al usuario.

PublishView

JPanel que implementa IPublishView

PublishController

Quizás esta clase no haga falta

ControllerRegister

Registro de controladores. Cualquier plugin debe registrar aquí su controlador.

Operaciones

addController(key_controller:String, clase:Class) Registramos el controlador identificado por la cadena "key_controller"

getControllersNames():Set Obtenemos los identificadores de todos los controladores registrados

getInstance(key_controller:String, clase:Class) Obtengo una instancia del controlador especificado

La extensión de publicación debe ser capaz de generar los ficheros de configuración en varios servidores, por ello se ha empleado una arquitectura extensible mediante plugins.

En esta primera versión de la extensión, se han creado dos plugins, uno para el servidor Mapserver y otro para el servidor Geoserver.

Subsistemas de análisis de los plugins

La arquitectura del plugin utilizará el framework que define la extensión de publicación. Vemos entonces cómo el plugin emplea la parte de GUI y modelServers de la extensión de publicación para ampliar su funcionalidad al servidor específico de Mapserver.

Tenemos que el plugin está compuesto por una parte de interfaz gráfico y otra parte de librería que generará los ficheros de configuración de Mapserver.

Subsistemas de análisis de publishMapserver

Para integrar la parte gráfica específica de Mapserver en la extensión de publicación, lo único que hay que hacer es crear el controlador correspondiente que ofrezca los paneles a la extensión de publicación. Existe un controlador MapserverController del tipo PublishController que aportará las vistas de las entidades del modelo de Mapserver, por tanto tendremos una vista (del tipo PublishView) para el servidor, una para cada servicio y otra para cada recurso remoto asociado al servicio.

Mapserver WMS

En el caso del servicio WMS que ofrece Mapserver, se empleará el controlador por defecto que muestra en un árbol los servicios y los recursos remotos. Este controlador tendrá un tipo de vista por cada uno de los paneles.

GUI referente a WMS de publishMapserver

The new Gazetteer client offers the possibility to add new protocols. The idea is that anyone can add him own driver to manage its own protocol.

To add a new gazetteer protocol the first step is to create a new driver that just is a class that has to inherit of the IGazetteerServiceDriver interface. This interface forces to implement the common methods that all the Gazetteer drivers have to had. There is also an abstract class named AbstractGazetteerServiceDriver than implements this interface and it has a default implementation for some of the driver methods (but the using of this class is not necessary). Next figure shows the hierarchy:

GazetteerCapabilities getCapabilities(URI uri) throws Exception;

public Feature[] getFeature(URI uri, Query query) throws Exception;

public String getServiceName();

GazetteerDriverRegister register = GazetteerDriverRegister.getInstance();
register.register(new ExampleNewDriver());

public SearchAditionalPropertiesPanel getAditionalSearchPanel()

La disponibilidad de metadatos de los datos es algo fundamental en el mundo de la Información Geográfica para el descubrimiento y acceso a los mismos. Sin la existencia de metadatos que identifiquen y definan los datos, aún existentes y disponibles, no es posible su localización por parte de usuarios externos. La producción de metadatos asociados a los datos es un trabajo laborioso que consume gran cantidad de recursos, por ello es una tarea que normalmente queda relevada a un segundo plano a pesar de su relevante importancia. gvSIG no dispone en la actualidad de capacidad de gestión ni edición de metadatos, no siendo posible la publicación en Servicios de Catálogo (OpenGIS® Catalogue Service) de los datos que creamos o modificamos.

La extensión del Gestor de Metadatos pretende incorporar en gvSIG la capacidad de extracción semiautomática y escalada de metadatos de las fuentes de datos, haciendo que la tarea de documentación de los datos sea mucho más sencilla y eficiente. La extracción semiautomática de metadatos implica que el gestor sea capaz, directamente desde la fuente de datos y sin intervención del usuario, de extraer metadatos, que ofrecerán al usuario información de los datos sobre los que trabaja. Los metadatos que no puedan ser extraídos de forma automática podrán ser editados por el usuario y gestionados por el gestor de metadatos de forma que no sea necesario la intervención del usuario de forma reiterativa, si no que sean almacenados en plantillas e información adicional para posteriores usos. Todo el desarrollo, tal y como gvSIG, se realizará bajo licencia GPL.

El trabajo consiste en desarrollar una nueva extensión sobre la aplicación gvSIG, dotándolo de la funcionalidad de gestión de metadatos,  con el fin de obtener una aplicación con la capacidad de extracción semiautomática de metadatos implícitos, la gestión de los mismos y la posibilidad de publicación en un servidor de catálogo.

Las principales funcionalidades a desarrollar son:

• Extracción de metadatos de recursos en el sistema. Como primera fase los recursos a documentar estarán limitados a:
  • las capas de una vista, en concreto capas vectoriales procedentes de fuentes de datos de ficheros shape.
  • Metadatos inherentes al sistema y al usuario
• Gestión de metadatos de contactos del usuario
• Generación de un formato de metadato interno
• Edición de metadatos.
• Publicación de metadatos a un servidor de catálogo.

• MDML: formato interno en el que se trabaja.
• Metadato: Información asociada a un recurso cartográfico.
• Recurso cartográfico: información sobre una entidad georeferrenciada . Por ejemplo un mapa, una feature, una cobertura, un metadato,etc.
• Service: protocolo de comunicación en la arquitectura cliente-servidor.
• Server: producto software que implementa la especificación de un servicio.
• Publicación: generación de los recursos necesarios (ficheros de configuración) para que funcione correctamente un servidor.
• Feature: Entidad cartográfica vectorial como un punto, línea o polígono.
• Topónimo: nombre que identifica una feature.
• SRS: Sistema de referencia espacial. Sistema de coordenadas de cualquier georreferenciación.
• Leyenda: lista explicativa que define los símbolos utilizados en un mapa o gráfico.

La extensión de metadatos almacenará y mantendrá los metadatos junto a los datos, adoptando la filosofía de que los metadatos forman parte de los datos, o por lo menos se deben acompañar siempre.

El gestor de metadatos en su interacción con las clases base de gvSIG, extenderá el modelo de objetos (fmap) dotando a los recursos identificados como posibles objetos a metadatar con la capacidad de recuperar y almacenar metadatos sobre si mismos. Estos recursos que en un principio se limitarán a capas serán objetos tales como vistas, features, procesos, etc.

Diagrama de contexto inicial: interacción entre extMetadata y FMap

Tres son los módulos que conforman la extensión: mdManager, mdPublish y mdExchange. A continuación, se muestran las interacciones existentes entre ellos.

Diagrama de contexto de extMetadata: interacción entre los módulos de la extensión

mdManager

En este módulo encontramos la lógica y GUI's del editor de metadatos, así como del editor de contactos.

mdPublish

Se encarga de validar y publicar los metadatos, extraídos previamente, en un servicio de catálogo web.

mdExchange

Se encarga de realizar las tranformaciones, con ayuda de hojas de estilo XSLT, entre formatos XML de metadatos. Es utilizado por los módulos mdPublish y mdManager.

Las pruebas que se describen a continuación hacen referencia a los test que intentan validar la correcta implementación de la funcionalidad de la extensión, es decir, la correcta extracción, almacenado, edición y publicación de los metadatos de una capa vectorial. Por tanto, habrá un caso de prueba por cada uno de los casos de uso de alto nivel que describíamos anteriormente. Con estas pruebas conseguiremos validar la correcta integración de los distintos subsistemas, exceptuando el gui que llevará un tratamiento especial en cuanto a pruebas.

Cuando entremos en detalle en cada subsistema o bloque, especificaremos con más detalle las pruebas asociadas a cada bloque en particular. En estos test de más bajo nivel se intentará validar la funcionalidad específica de cada subsistema.

En esta primera versión de la extensión de metadatos, se va a desarrollar la publicación solo para GeoNetwork (CS-W). Por tanto, y viendo los casos de uso de alto nivel, los casos de prueba son los siguientes:

Caso de uso "Abrir capa sin metadatos existentes":

Puesto que para persistir los metadatos usamos ficheros locales, en el caso de abrir una capa que no posea metadatos anteriores deberemos generar de forma un fichero acorde al formato MDML que contenga los metadatos que se hayan podido extraer de forma automática. Por lo tanto este conjunto de pruebas se basarán en la existencia de dicho fichero y en su correcta estructura de acuerdo al formato interno MDML.

Caso de uso "Abrir capa con metadatos existentes":

En este caso nos encontramos que, al abrir la capa, ya existe un fichero en formato MDML con metadatos sobre ella. Las pruebas realizadas sobre este caso de uso consistirán en a partir del fichero generar un objeto Metadata que nos permita visualizarlo correctamente  en el editor de metadatos.

Caso de uso "Publicación en GeoNetwork":

En este conjunto de pruebas se deberá considerar los siguientes aspectos relacionados con los requisitos:

• Obtención del objeto Metadata asociado al Layer.
• Correcta conexión y validación contra el server.
• Transformación del MDML al formato standard destino.

Por tanto se espera que tras la ejecución de este test se ha creado una petición HTTP correcta de acuerdo con el server GeoNetwork, que nos permita incorporar los metadatos en dicho server.

Caso de uso "Importar metadatos":

Las pruebas realizadas sobre esta funcionalidad consistirán en importar un fichero XML con un formato soportado por la extensión. Para ello la extensión deberá realizar la transformación pertinente al formato MDML y posteriormente construir un objeto Metadata que nos permita visualizarlo correctamente en el editor de metadatos.

Caso de uso "Exportar metadatos":

En este caso nos interesa almacenar en nuestra máquina los metadatos asociados a una capa, que estamos visualizando en el editor, en un fichero con el formato XML que elijamos. Para testear este caso de uso, debemos comprobar que los ficheros generados con la opción exportar son correctos de acuerdo al formato que hemos indicado.

Extracción automática de metadatos

La extracción automática de metadatos se realizará cada vez que el usuario realice las siguientes operaciones sobre una capa:

Diagrama de casos de uso para la extracción automática de metadatos

Realmente, nos referimos a extracción semiautomática porqué los metadatos serán obtenidos de diversas maneras:

• Extracción automática: directamente desde la fuente de datos y sin intervención del usuario, el gestor será capaz de extraer metadatos, que ofrecerán al usuario información de los datos sobre los que trabaja.
• Edición manual: metadatos que no pueden ser extraídos de forma automática o que, por requisito del usuario, podrán ser editados manualmente y gestionados por el gestor de metadatos de forma que no sea necesaria la intervención del usuario de forma reiterativa, si no que sean almacenados en plantillas para posteriores usos.

La extensión de metadatos almacenará y mantendrá los metadatos junto a los datos adoptando la filosofía de que los metadatos forman parte de los datos, o por lo menos se deben acompañar siempre.

En última instancia, el usuario puede publicar sus datos en un servido de Catálogo (por ejemplo, Geonetwork) o exportar los metadatos para visualizarlos mediante otro editos de metadatos (por ejemplo, CatMDEdit).

Módulo mdEditor

Una vez el usuario tiene una capa abierta (y por lo tanto sus metadatos asociados disponibles) tiene varias opciones a realizar con los metadatos:

Diagrama de casos de uso general de metadatos

Módulo mdExchange

El usuario no interacciona directamente con el módulo mdExchange así que, en los dos diagramas mostrados a continuación, los actores son el módulo gestor de metadatos y el módulo de publicación, respectivamente.

Diagrama de casos de uso con el módulo gestor de metadatos como actor

   Diagrama de casos de uso con el módulo de publicación como actor

Módulo mdPublisher

Cuando el usuario selecciona la opción de publicar bien desde el editor de metadatos o desde el menú aparecerá una GUI que le permitirá seleccionar el origen de los metadatos (layer), el host dode deseamos publicar y las opciones de publicación de que dispone el host seleccionado. Y finalmente publicar los metadatos.

Diagrama de casos de uso de mdPublish

Análisis de Requerimientos

Requerimiento RQ1: Soporte de Metadatos en gvSIG

Se quiere incorporar a gvSIG el soporte de gestión de Metadatos asociados a cualquiera de los datos que maneja la aplicación. Este soporte debe ser un servicio del núcleo de gvSIG, que debe permitir la generación y consulta de Metadatos, tanto en cualquiera de los niveles de aplicación (subdriver, FMap y gvSIG), como en el Core y las distintas extensiones. Dicho soporte deberá contemplar la persistencia de los Metadatos y la posibilidad de consultar qué Metadatos está gestionando gvSIG.

Los Metadatos son datos sobre los datos (wikipedia) . Se emplean para describir datos individuales, contenidos o grupos de datos, y sirven para facilitar la comprensión, uso y gestión de los datos. Cada Metadato tendrá una serie de Atributos o Elementos, cuyos valores definen las características del dato al que se asocia el Metadato.

Al incorporar este requerimiento a gvSIG, cualquier componente que represente algún tipo de datos, podrá ser interrogado para obtener su Metadato. Dichos componentes serán marcados como Metadatables.

A nivel de modelo, un metadato será una entidad con una serie de atributos y tipos definibles de forma dinámica, con una jerarquía de datos similar a la que define el modelo de datos de gvSIG (proyecto -> documento -> capa -> ...). Así, la estructura de un Metadato se podrá definir de forma dinámica, y consultar los tipos de datos de sus Elementos.

Relación con el modelo de datos de gvSIG

A continuación se muestra un diagrama que tiene como objetivo detectar la relación que tienen los Metadatos con el modelo de datos conceptual de gvSIG Core. Se indican también algunos ejemplos de elementos de Metadatos que se pueden extraer en cada caso.

Relación con el modelo de datos de gvSIG

Como se puede ver, existe un paralelismo entre la estructura de datos de gvSIG y la estructura de los Metadatos. Se define una jerarquía en forma de árbol que empieza a nivel de la propia aplicación y va descendiendo por el árbol de elementos que maneja gvSIG.

Otras extensiones aportarán Metadatos de forma similar al core, ya que generalmente aportarán sus propios elementos dentro del modelo de gvSIG: otros tipos de capas, documentos, drivers, etc. Si las extensiones tienen Metadatos generales que no pertenecen a la estructura del Core, se pueden asociar a nivel de Aplicación, incluyendo un Metadato específico para cada extensión.

De este requerimiento surgen los subrequerimientos RQ1.1 y RQ1.2.

Requerimiento RQ1.1: Persistencia de Metadatos

Dado que los Metadatos formarán parte intrínseca de un proyecto gvSIG, deberán almacenarse como parte del mismo, junto con los propios datos del proyecto y la configuración del mismo.

En gvSIG, cuando se guarda un proyecto, se recorre el árbol de componentes del proyecto para solicitar su configuración en formato XML. De estos componentes, los que sean de tipo Metadatable, deberán incluir sus Metadatos en su configuración de proyecto a persistir.

Será conveniente proporcionar un mecanismo genérico que permita generar la configuración XML correspondiente a partir de un Metadato. También se incluirá el mecanismo inverso, que permita construir un Metadato a partir de la configuración de proyecto.

De este requerimiento surgen una serie de casos de uso:

Casos de uso de persistencia de Metadatos.

Note

DEFINIR

Requerimiento RQ1.2: Registro de Metadatos

Se incorporará a gvSIG un servicio centralizado de registro de Metadatos, en el que se guarden y consulten la definición de los Metadatos de gvSIG.

Un registro de Metadatos (wikipedia) es un repositorio centralizado de definiciones de Metadatos, dónde se almacenan y mantienen de forma controlada. Una definición de Metadato especifica el formato del mismo, los atributos o Elementos que lo componen y la descripción y tipo de datos de cada uno de ellos.

Este registro permitirá que, cualquier componente, registre de forma dinámica los Metadatos o Elementos que aporta a la jerarquía de Metadatos de gvSIG. Además permitirá también la consulta de las definiciones de Metadatos disponibles, así como de los Elementos y tipos de datos que los constituyen.

Diagrama de entidades

A partir del análisis de los requisitos se definen una serie de entidades para la gestión de los Metadatos en gvSIG. A continuación se muestra un diagrama con dichas entidades y su interacción:

Diagrama de entidades

Diagrama de contexto

A continuación se muestra un diagrama que muestra las entidades definidas en el apartado anterior, dentro del contexto de gvSIG.

Las entidades principales de gestión de Metadatos, formarán parte del propio core de gvSIG, al tratarse de un servicio central de la aplicación.

La extensión de Metadatos se encargará de gestionar la parte de presentación de los Metadatos, incluyendo la visualización y edición de Metadatos, así como la visualización y edición sobre plantillas de formatos de Metadatos estándar.

Diagrama de contexto

Descripción

Todo componente de gvSIG al que se pueden asociar Metadatos. Por ej: Proyecto, Documento, Capa, etc.

Responsabilidades:

• Generar los Metadatos de sus datos.
• Persistir sus Metadatos.
• Permitir la consulta de sus Metadatos.

Introducción

Se encarga de la creación y serialización de Metadatos, acorde a su definición.

Responsabilidades:

• Crear un Metadato a partir de su definición.
• Serializar un Metadato a XML para ser incluido en la persistencia de un proyecto.
• Recrear un Metadato a partir del XML de la persistencia de proyecto.

Introducción

El registro de Metadatos se encarga de gestionar la lista de definiciones de Metadatos.

Una definición de Metadatos especifica el formato de un Metadato para un elemento de gvSIG (proyecto, documento, capa, etc.). Es decir, indica qué elementos va a contener el Metadatos, y sus tipos de datos.

Por otro lado, gestionará también la asociación entre sinónimos y las definiciones de Metadatos. Los sinónimos especifican una relación entre un Metadato en gvSIG y el mismo Metadato en otro formato de Metadatos externo.

Responsabilidades:

• Registrar definiciones de Metadato, Elementos y tipos de datos.
• Permitir la consulta de definiciones de Metadato.
• Asociar mediante sinónimos, Elementos de Metadatos con su equivalente en formatos de Metadato estándar.

Introducción

Se encarga de la edición de Metadatos de usuario, es decir, aquellos que no pueden ser generados a partir de los datos.

Responsabilidades:

• Incluir en el interfaz de usuario de gvSIG pantallas de visualización y edición de los Metadatos.
• Permitir la visualización y edición de Metadatos, con plantillas de formatos de Metadatos estándar.

Introducción

La extracción de Metadatos no es realmente un subsistema independiente, sino que será un proceso que formará parte de cada uno de los Drivers o Datasource de gvSIG. De la misma forma que son capaces de cargar los datos para una capa, deberán extraer los Metadatos correspondientes.

Introducción

La persistencia de los Metadatos deberá ser capaz de cubrir las siguientes necesidades:

• Creación y actualización de datos con una estructura jerárquica.
• Consulta de datos, según su posición jerárquica, y a través de consultas según alguno de sus datos.
• Facilitar la importación y exportación de parte o todos los Metadatos.
• Permitir el registro a eventos ante cambios en determinados Metadatos.

Sería interesante que soportara también transacciones en la modificación de los Metadatos.

Describir cómo serían los procesos de:

• Captura de Metadatos: a través de listeners siempre que sea posible, o desde la implementación de los módulos que correspondan.
• Repositorio de metadatos: consulta y escritura de metadatos, tipos, sinónimos, etc.
• Importación y exportación a formatos estándar.

Proponer y justificar el uso de un JCR, como por ejemplo Apache Jackrabbit. Ver funcionalidad que aporta y como encaja en las necesidades.

• Estudiar relación entre metadatos, la configuración y las preferencias de usuario que se guardan actualmente en gvSIG. Serian necesarias las segundas?
• El diccionario contendrá el catálogo de tipos de Metadatos. Proveerá un interfaz que permita interrogar por la lista de tipos de metadatos disponibles, así como incluir tipos. El core de gvSIG incluirá los requeridos por los distintos formatos estándares de Metadatos, y cada extensión o componente podrá incluir los suyos propios. ¿Permitir sólo Metadatos de los que exista una definición en el diccionario?
• Como opción de reutilización, puede ofrecer un interfaz de exportación/importación en formato XML MDML. Así se pueden reutilizar los Templates actuales, con su XSL de conversión a/desde su formato estándar.

Los templates podrían ser grupos de extensiones de entrada, salida, conversión, etc.

Buscar otro nombre, ya que no se corresponden con, por ejemplo, los Templates de GeoNetwork.

• Cada proyecto o extensión debería publicar en algún lugar la lista de Metadatos que proporciona. ¿Deberían ser validados por gvSIG?
• Implementar el modelo de Metadatos sobre EMF?
• Establecer un mecanismo para establecer la relación jerárquica entre los Metadatos.

LibUI es una libería de soporte, independiente de gvSIG, que proporciona a los desarrolladores una serie de controles, paneles y otras herramientas que pueden resultar de utilidad en un momento determinado.

En este texto vamos a detallar todos los componentes LibUI que aparecen con la finalidad de proporcionar una herramienta de consulta útil para desarrolladores. Mostraremos una breve descripción, capturas de su utilización y un sencillo ejemplo de ejecución de cada una de estas herramientas.

Las herramientas disponibles en la librería son:

• Herramientas Básicas

  • Modificación de JButton

    • JButton

  • Panel con GridBagLayout

    • GridBagLayoutPanel

  • PopUp de edición

    • JOptionsEditionByMousePopUpMenu

  • Campo numérico con dos botones

    • NumberRange
    • TextIncreaser

  • EditorPane para previsualización

    • JTextPreview

  • TextField´s y Extensiones

    • JDecimalField
    • DataInputContainer y CoordDataInputContainer

  • Date Controls

    • DateComboBox
    • JCalendarCDatePanel y JCalendarDatePanel
    • JCalendarDateDialog

  • Extensiones de ComboBox

    • ComboBoxItemSeeker
    • ComboScale
    • ComboButton

• Composición de controles y controles más especificos

  • Lista con Drag and Drop

    • JDnDList

  • Tip multi línea

    • MultiLineToolTip

  • Filter panel

    • FilterButtonsPanel
    • FilterQueryJPanel

  • Conjunto de herramientas para implementar un Tree en un panel

    • TreeTable
    • TreeListContainer

  • Panel con botones

    • AcceptCancelPanel
    • ButtonBar

  • Botones y barra para navegación.

    • Pager
    • SliderTextContainer

  • Panel con gráfico.

    • GraphicPanel

  • Diálogo para abrir ficheros.

    • OpenFileContainer

  • Panel con tabla. (Posibilidad de varios modelos de tablas)

    • TableContainer

• Apéndice

  • Clase Messages
    • Messages

Es la clase sobreescrita JButton para utilizar por los desarrolladores de gvSIG con el fin de aunar criterios a la hora de diseñar los botones a utilizar en la aplicación. Lo que proporciona esta clase es el tamaño estándar de los botones, que no deben ser más pequeños que el tamaño establecido. Si por necesdidad del desarrolloador fuera necesario etiquetar el botón con más caracteres de los que caben en el tamaño estándar del botón, la clase evitará utilizar los carácteres "..." y lo que hará será aumentar el ancho del botón en el tamaño mínimo necesario.

A continuación mostramos un ejemplo de utilización.

Se observa el tamaño estándar de un botón y como ajusta el ancho para otro texto más extenso.

Al ser una extensión de JButton con la particularidad del tamaño establecido, la forma de utilizarlo es la misma que la del JButton original

JButton b2= new JButton("Botón");  //Constructor
content.addComponent(b2);  //Lo añadimos al panel

Esta clase extiende de JPanel y lo que hace es crear un JPanel con un GridBagLayout que permite añadir facilmente nuevos componentes en filas que son automáticamente insertadas y alineadas en el panel usando los métodos apropiados que se proporcionan.

Además, se propociona la clase JBlank que lo que hace es crear un panel en blanco con la finalidad de que sea utilizado como separador entre filas de componentes añadidos en el Layout.

A continuación se muestra unas capturas de la utilización de esta clase.

Ejemplo de utilización de la clase GridBagLayoutPanel.

El código empleado es el siguiente.

Creamos un objeto de la clase GridBagLayoutPanel y actualizamos el tamaño que queremos

GridBagLayoutPanel content= new GridBagLayoutPanel();
content.setPreferredSize(new Dimension(300,200));

Creamos 4 botones

JButton b1 = new JButton("Prueba1");
JButton b2 = new JButton("Prueba2");
JButton b3 = new JButton("Prueba3");
JButton b4 = new JButton("Prueba4");                  

Añadimos tres componentes en una fila, ajustando los tamaños al ancho del panel

content.addComponent(b1,b2,b3, 1);

Añadimos Blank´s para separar

content.addBlank();
content.addBlank();
content.addBlank();
content.addBlank();
content.addBlank();
content.addBlank();
content.addBlank();

Y por último añadimos el último botón que también ocupe todo la fila con el Inset indicado

content.addComponent(b4,1,new Insets(1,0,0,1));

Esta clase crea un menú PopUp para poder incorporarlo a elementos de edición de texto como es JTextField por ejemplo. El menú que se crea posee los siguientes botones:

• edit undo
• edit redo
• edit cut
• edit copy
• edit paste
• edit delete
• edit selectall

Se incorpora herramientas para modificar la visisbilidad de las diferentes acciones que se pueden realizar desde el PopUp según desee el usuario.

La clase deja en manos del desarrollador la implentación de las acciones que realizarán los distintos botones del PopUp, así como la acción que lo activará (normalmente al pulsar el botón derecho del ratón sobre un campo de edición de texto).

A continuación se muestra una imagen del menú PopUp que se crea utilizando esta clase.

El código necesario para utilizar la clase es el siguiente. Se observa el constructor y el evento necesario para que aparezca el menú cuando se pulsa el tercer botón del ratón

MouseAdapter editorMouseListener = new MouseAdapter() {
                      
                     public void mouseClicked(MouseEvent e) {
                              
                              JOptionsEditionByMousePopupMenu panel= new JOptionsEditionByMousePopupMenu();
                              Logger logger = Logger.getLogger(JTextField.class.getClass());
                              logger.debug("MOUSE-LISTENER : MOUSE-mouseClicked!" + e.getButton());
                              logger.debug("MOUSE-LISTENER : MOUSE-mouseClicked!" +e.isPopupTrigger());
                              
                              if (e.getButton() == MouseEvent.BUTTON3) {
                                     // Enable the "Select-All" option (by default it's always enabled)
                                     panel.setEnabledSelectAllOption(true);
                                     panel.setLocation((int)text.getLocationOnScreen().getX() + e.getX(), (int)text.getLocationOnScreen().getY() + e.getY());
                                     panel.setInvoker(text);
                                     panel.setVisible(true);
                  
                               }
                     }
};

NumberRange extiende de Panel. Esta clase proporciona un campo de texto y dos botones. El funcionamiento es el siguiente, la clase crea un JNumberText cuyo valor se podrá incrementar o decrementar mediante dos botones (JButton). Mediante el constructor podremos asignarle el valor inicial y final, así como el valor con el que queremos que se inicialice el campo de texto.Además también podemos indicarle mediante el constructor el número de dígitos que queremos mostrar en el campo. Lo podemos ver en las siguientes imágenes.

En la imagen el "Number Range" se ha creado con los parámetros: dígitos mostrados 2; valor inicial 0; valor mínimo -5 y valor máximo 5.

En las siguientes líneas de código se muestra el constructor y como añadir el componente al panel. En el constructor se incluyen el tamaño del campo, el valor inicial que se muestra en TextField y los valores máximo y mínimo que podrá alcanzar el número del campo. La segunda línea es la función que permite insertar el componente NumberRange en un JPanel ya creado

ejamplo_numberRange a = new ejamplo_numberRange(2,0,-5,5);
c.add(a);

Esta clase crea un campo de texto y dos botones para aumentar el o disminuir el valor que aparece en el campo de texto. Están implementados listeners para que cuando se pulsa el botón más o el botón menos se ejecute la acción correspondiente pero no se gestiona que el valor que se introduzca a mano sea de un tipo determinado, esto debe ser tenido en cuenta por el desarrollador.

Captura de su uso.

Ejemplo de la utilización de la clase.

Código generado para implementar el ejemplo.

Constructor, los parámetros que se le pasan son los siguientes, ancho del campo de texto, minimo valor, máximo valor, valor por defecto que aparecerá en el cuadro de texto y por último "true" si queremos que los botones aparezcan a la derecha del texto o "false" si queremos que salgan a la izquierda

TextIncreaserContainer tic1 = new TextIncreaserContainer(70, 0, 10, 0, true);

Modificamos el valor a mostrar en el campo de texto

tic1.setValue(2.5);

Y por último añadimos el panel al frame

frame.getContentPane().add(tic1);

Esta clase extiende JEditorPane, y permite guardar en una cadena el formato elegido para el texto que se quiera mostrar. Se elige el formato de la cadena de texto que se desea mostrar, es decir, la fuente, si negrita o cursiva, etc. La clase modificará en la cadena que se guarda los cambio realizados al cambiar la fuente.

Se muestra un ejemplo de como mostraría la cadena "Esto es una prueba" con formato de fuente texto plano.

Ejemplo con texto plano.

Y otro de como mostraría la misma cadena con formato ITALIC.

Ejemplo con texto en negrita (BOLD)

El código necesario para generar estos ejemplos se detalla a continuación.

Constructor para crear el objeto

JTextPreview txt= new JTextPreview();

Creamos una fuente de texto con el siguiente formato, en negrita y con tamaño de texto 20, lo asignamos al EditorPane, y establecemos el texto a mostrar

Font font= new Font("Serif", Font.BOLD,20);
txt.setFont(font);
txt.setText("Esto es una prueba.");

Por último lo asignamos al panel

content.add(txt);

JDecimalField extiende la clase IoSTextField y permite la entrada de valores en formato BigDecimal. Esta clase está relacionada con BigDecimalFormat y se utiliza para crear un campo de texto con este formato de datos. La clase internamente traducirá la cadena de texto introducida en el TextField en un objeto de la clase BigDecimal que pueda ser utilizado por el desarrollador.

A continuación un ejemplo de uso de la clase.

En la imagen se observa el resultado de crear un JDecimalField.

A continuación se explica como se ha utilizado la clase para obtener este cuadro de texto.

Esta línea permite la creación de un objeto JDecimalField con 4 columnas, con autoformato y manteniendo el foco con la entrada de algún valor no válido

JDecimalField test =new JDecimalField(4,true,true);

Esta línea de código permite establecer una escala, es decir, cuantos decimales se mostrarán como mínimo y como máximo. En el caso que el número a introducir tenga menos decimales que el valor mínimo de escala se completará con ceros a la izquierda. Si existen más decimales que el valor máximo de la escala se aplicará un redondeo para ajustar a la escala

test.setScale(3,7);

Con este fragmento de código creamos el número en formato BigDecimal que queremos incluir y lo mostramos en el TextField

BigDecimal bd= new BigDecimal("2.01234567890123456789");
test.setValue(bd);

Apéndice.

Otras clases de interés:

• "IoSTextField" es una clase abstracta que extiende JTextField y que tiene una serie de particularidades. En lugar de mostrar la última parte escrita muestra la parte delantera del texto (leading text) introducido en el TextField. Controla la ganancia y pérdida de foco por parte del TextField. Permite formateo de texto y la posibilidad de mantener el foco aunque el valor introducido sea no válido (en relación con el formato de texto introducido, si se ha optado por introducir un formato de texto).
• "BigDecimalFormat" es una clase que extiende de DecimalFormat y se utiliza para formatear números en formato BigDecimal, es decir, la clase permite utilizar un patrón establecido por el desarrollador con el formato que desee para el número BigDecimal. También se aplicará un redondeo, seleccionado por el usuario, en el caso que sea necesario. El formato BigDecimal surge como solución al problema aparecido con el tipo de datos Double ya que éste no puede representar números del tipo "0.01" de forma precisa ya que el número representa "1/100" que en binario es periódico, luego para representarlo se trunca o redondean valores con lo que se pierde precisión y a la hora de operar con estos valores se incurre en un error y no se obtendrá el valor esperado. BigDecimal soluciona este problema.
• "JNumberField" es una clase que extiende de IoSTextField y permite la entrada de valores numéricos. Los tipos numéricos soportados son BigInteger, Integer y Long. La clase la puede utilizar el desarrollador para introducir valores en los formatos antes mencionados mediante un campo de texto.

DataInputContainer

Esta clase extiende de JPanel e implementa FocusListener y KeyListener. El objetivo es crear un panel con un JTextField que detecte que el tipo de carácteres introducidos sea numérico o alfanumérico. Para ello implementa una serie de métodos para controlarlo. Existe un método, como se verá en el ejemplo, que permite cambiar de un formato de carácter permitido a otro. La clase incorpora una etiqueta asociada al campo de texto que por defecto es "JLabel:".

A cotinuación se muestra una imagen del campo de texto.

Imagen de un ejemplo de utilización de la clase DataInputContainer.

Un ejemplo de utilización de la clase es el siguiente.

Creamos el objeto DataInputContainer

DataInputContainer data = new DataInputContainer();

Establecemos que solo acepte carácteres numéricos

data.setCaracter(false);

Añadimos la etiqueta y establecemos el tamaño que deseamos que tenga el TextField

data.setLabelText("Prueba");
data.setPreferredSize(new Dimension(100,25));

Añadimos el TextField al frame creado para el ejemplo

frame.getContentPane().add(p);

CoordDataInputContainer

Una extensión de esta clase es "CoordDataInputContainer" que consta de cuatro DataInputContainer en un panel con disposición BordeLayout. La clase contiene los métodos para manipulación de los valores que se introducen (set y get). Al ser cuatro DataInputContainer se puede establecer si deseamos que sean carácteres numéricos o alfanuméricos. Además permite etiquetar los componentes de dos en dos mediante unos iconos. Existe un método que permite etiquetar los TextFields, el "border" que incluye y dos etiquetas identificativas para cada par de componentes. A continuación se expone un ejemplo.

Se incluye una imagen de muestra.

CoordDataInputContainer.

El código necesario para crear esta clase es el siguiente.

Constructor

CoordDataInputContainer coord = new CoordDataInputContainer();

Establecemos los parámetros del panel, nombre para el "border", para cada componente y para cada par de componentes

coord.setParameters("Coordenadas pixel", "Sup.Izq", "X","Y","Inf.Der","X","Y");

Establecemos que tipo de valores queremos que acepten los campos de texto

coord.setDecimalValues(true);
coord.setCaracterValues(false);

Por último, lo añadimos al frame

frame.getContentPane().add(coord);

Descripción

Esta clase crea un ComboBox con fechas. Cuando hacemos clic en el desplegable del ComboBox creará un mensaje popup con un calendario en el que podremos seleccionar la fecha deseada. A continuación se ocultará el popup y la fecha seleccionada aparecerá en el recuadro del ComboBox. El formato en el que se mostrará la fecha es el siguiente:

mes día, año (Ejemplo: jul 10, 2007).

Dentro del "popup" nos encontramos con un calendario mensual en el que aparecen dos tipos de navegadores representados por "<" ">" que se utilizan para cambiar de mes y "<<" ">>" que se utilizan para cambiar de año.

Imágenes

DateComboBox. Aparecen los ComboBox sin desplegar.

DateComboBox. Se muestra el PopUp que aparece cuando desplegamos el ComboBox

DateComboBox. Se muestra como queda el ComboBox despues de seleccionar una fecha en el PopUp

A continuación se mostrará el código indicativo de como usar la clase.

// En esta línea de código mostramos la llamada al constructor

DateComboBox dcb = new DateComboBox();

// Modificamos la propiedad para que nos permita editarlo

dcb.setEditable(true);

// Y lo añadimos al panel (JPanel), igual que un ComboBox

c.add(dcb); (c es el panel)

Estas dos clases extienden JPanel. Crean un panel para incluirlo en otros paneles. En el panel que crea la clase JCalendarCDatePanel se inserta un ComboBox que al desplegarlo aparece un mensaje PopUp con un calendario para que el usuario seleccione la fecha que desee. La fecha seleccionada aparecerá en el campo del ComboBox. La limitación de esta clase es que el mensaje PopUp que aparece no se puede desplazar ni redimensionar a voluntad del usuario.

Este problema se ha corregido en la clase JCalendarDatePanel. Versión similar a JCalendarCDatePanel pero se soluciona la limitación de ésta usando internamente un JButton y un JDialog que contiene un CalendarDateDialog. Así el usuario por defecto ve la fecha sobre el JButton, y si lo pulsa aparece el JDialog, sobre el que puede seleccionar la fecha deseada y a su vez puede desplazar el componente donde más desea por la pantalla. Una vez seleccionada la fecha, el JDialog deja de estar visible y en el JButton se puede ver la nueva fecha.

A continuación se incorporan ejemplos de las dos clases implementadas.

JCalendarCDate. Ejemplo de uso con el calendario no desplegado.

JCalendarCDate. Ejemplo de uso con el calendario desplegado.

JCalendarDate. Ejemplo de uso con el calendario no desplegado.

JCalendarDate. Ejemplo de uso con el calendario desplegado.

El código necesario para generar los ejemplos ha sido el siguiente

JCalendarCDatePanel t = new JCalendarCDatePanel();

JCalendarDatePanel t = new JCalendarDatePanel();

// Y posteriormente incluirlos en el panel

content.add(t);

La clase extiende JDialog. Esta clase implementa en un diálogo un calendario para que pueda ser utilizado por otros componentes gráficos. En el ejemplo siguiente se ha utilizado para la implementación un JButton que lo invoca mediante la implementación de un listener para recoger cuando se pulsa un botón del ratón sobre él. El diálogo que se crea se puede dsplazar y redimensionar a voluntad del usuario.

A continuación se muestran imágenes con el ejemplo de la clase.

Se observa el botón que utilizamos para invocar al diálogo que contiene al calendario.

En la imágen se puede ver el diálogo que se crea cuando pulsamos el botón.

El código necesario es el siguiente:

Constructor de la clase

JCalendarDateDialog t=new JCalendarDateDialog();

Creamos un botón con un listener que al ser pulsado invoca al Dialog del calendario y lo añadimos al panel

JButton jButton = new JButton();
jButton.setPreferredSize(new Dimension(widthJB, heightJB));
jButton.setText(Messages.getText("date"));
jButton.addMouseListener(new MouseAdapter() {
      public void mouseClicked(MouseEvent e) {
              t.setVisible(true);
              t.setLocationRelativeTo(null);
              System.out.println("Selected date: " + new SimpleDateFormat("yyyy-MM-dd", Locale.getDefault()).format(t.getDate()));
                      }
      }
);
jF.getContentPane().add(jButton);

Esta clase es una extensión de DefaultComboBox y permite realizar búsquedas de objetos y mostrarlos en un ComboBox. El objeto devuelto depende de la configuracón que utilicemos y de la búsqueda que realicemos. El modelo que representa esta clase puede ser configurado con tres atributos:

Comportamiento inicial (Start Behavior): Configura como devolverá los items al principio (siempre devuelve todos lo items):

• MAINTAIN_ORIGINAL_POSITION_START: Devuelve los items en el orden en el que se habían introducido.
• ORDERED_START: Devuelve los items ordenados.
• DISORDERED_START: Devuelve los items desordenados.

Comportamiento de búsqueda (Search Behavior): Configura cómo devolverá un objeto al realizar una búsqueda:

• MAINTAIN_ORIGINAL_POSITION_ALL_ITEMS_SEARCH: Devuelve todos los objetos en el orden en que han sido introducidos.
• ORDERED_ALL_ITEMS_SEARCH: Devuelve todos los items ordenados.
• DISORDERED_ALL_ITEMS_SEARCH: Devuelve todos los objetos desordenados.
• MAINTAIN_ORIGINAL_POSITION_DYNAMIC_SEARCH: Devuelve los items cuyo valor de cadena comienza por una determinada serie de carácteres indicados. Los objetos son devueltos en el orden en el que han sido introducidos.
• ORDERED_DYNAMIC_SEARCH: Realiza una búsqueda similar a la configuración anterior pero en este caso los items devueltos son ordenados.
• DISORDERED_DYNAMIC_SEARCH: Realiza una búsqueda similar a las anteriores pero en esta configuración los items son devueltos de forma desordenado

Distinguir entre mayúsculas (Case Sensitive): Distingue entre mayúsculas y minúsculas a la hora de realizar la búsqueda:

• TRUE: Distingue entre mayúsculas y minúsculas cuando se realiza una búsqueda.
• FALSE: No distingue entre mayúsculas y minúsculas cuando se realiza la búsqueda.

Por defecto la clase está configurada de la siguiente manera:

• Start_Behavior = MAINTAIN_ORIGINAL_POSITION_START
• Search_Behavior = ORDERED_DYNAMIC_SEARCH
• Case_Sensitive = FALSE

El árbol de herencia se completa con "ComboBoxItemSeekerConfigurableModel" y con "ComboBoxSingularItemsSeekerConfigurableModel" que heredan de la clase anterior. La diferencia entre ambas es que la segunda esta optimizada para realizar búsquedas cuando no aparecen objetos repetidos, en cambio no funciona correctamente si aparecen items duplicados. En este caso utilizar la primera, aunque el tiempo empleado sea mayor.

En las siguientes imágenes vemos un ejemplo de su utilización:

En esta primera imagen se muestran todos los objetos introducidos según una configuración inicial.

En la segunda imágen se muestran los objetos ordenados y que comiencen por el carácter "a".

En la tercera imágen aparecen los objetos de la lista anterior que comienzan por "aa".

Los objetos que aparecen lo hacen según las configuraciones introducidas en el programa de test. Además incorpora un menú PopUp que se crea cuando hacemos clic con el botón derecho del ratón sobre el campo de edición del ComboBox. Este menú posee las acciones típicas de edición de texto como son copiar, pegar, cortar, etc. Para más información sobre el menú PopUp mencionado visitar la página JOptionsEditionByMousePopupMenu de esta misma sección.

A continuación se muestra los fragmentos de código de interés en la realización del programa de test.

El constructor de la clase

JComboBoxItemsSeekerConfigurable jCBSC = new JComboBoxItemsSeekerConfigurable();

La forma de incluir algunos items para realizar las pruebas de la utilización

jCBSD.addItem(new Item("libNomenclatorIGN_GUI"));
jCBSD.addItem(new Item("libRemoteServices"));
jCBSD.addItem(new Item("extNomenclatorIGN")); // Duplication test
jCBSD.addItem(new Item("libUI"));
jCBSD.addItem(new Item("libUI"));
jCBSD.addItem(new Item("a"));
jCBSD.addItem(new Item("aa"));
jCBSD.addItem(new Item("aaa"));
jCBSD.addItem(new Item("aaa"));

Diferentes líneas para activar o desactivar flags para realizar pruebas con los items anteriores

// Test a configuration of behavior of the search of JComboBoxSearcheableDynamic
//jCBSD.setSearchBehavior(AbstractDefaultComboBoxItemsSeekerConfigurableModel.ORDERED_ALL_ITEMS_SEARCH);
//jCBSD.setSearchBehavior(AbstractDefaultComboBoxItemsSeekerConfigurableModel.DISORDERED_ALL_ITEMS_SEARCH);
//jCBSD.setSearchBehavior(AbstractDefaultComboBoxItemsSeekerConfigurableModel.ORDERED_DYNAMIC_SEARCH);
//jCBSD.setSearchBehavior(AbstractDefaultComboBoxItemsSeekerConfigurableModel.DISORDERED_DYNAMIC_SEARCH);     
//jCBSD.setStartBehavior(AbstractDefaultComboBoxItemsSeekerConfigurableModel.ORDERED_START);
... 

Cambio de flags de control/vista

// Test the change of the flag 'onlyOneColor_Flag'
jCBSD.setOnlyOneColorOnText_Flag(true);

// Test the change of the flag 'beepEnabled_Flag'
jCBSD.setBeepEnabled_Flag(false);

// Test the change of the flag 'hidePopupIfThereAreNoItems_Flag'
jCBSD.setHidePopupIfThereAreNoItems_Flag(false);

// Test the change of the flag 'toForceSelectAnItem_Flag'
jCBSD.setToForceSelectAnItem_Flag(false);

Cambio de flags del modelo

DefaultComboBoxItemsSeekerConfigurableModel model = (DefaultComboBoxItemsSeekerConfigurableModel)
jCBSD.getModel();

// Test the change of the flag 'itemsShownInListBox_Flag'
model.setLanguageRules_Flag("en_US");
// model.setLanguageRules_Flag("fr_FR");
// model.setLanguageRules_Flag("es_ES");
                    
// Test the change of the flag 'caseSensitive_Flag'
model.setCaseSensitive_Flag(DefaultComboBoxItemsSeekerConfigurableModel.CASE_INSENSITIVE);
// model.setCaseSensitive_Flag(false);
                     
// Test the change of the flag 'itemsOrder_Flag'
model.setItemsOrder_Flag(DefaultComboBoxItemsSeekerConfigurableModel.MAINTAIN_POSITION);
// model.setItemsOrder_Flag(DefaultComboBoxItemsSeekerConfigurableModel.DISORDERED);
// model.setItemsOrder_Flag(DefaultComboBoxItemsSeekerConfigurableModel.ALPHABETICAL_ORDERED);

// Test the change of the flag 'itemsShownInListBox_Flag'
model.setShowAllItemsInListBox_Flag(DefaultComboBoxItemsSeekerConfigurableModel.SHOW_ALL_ITEMS);
// model.setShowAllItemsInListBox_Flag(true);
// model.setShowAllItemsInListBox_Flag(DefaultComboBoxItemsSeekerConfigurableModel.SHOW_ONLY_MATCHES);
// model.setShowAllItemsInListBox_Flag(false);

Es una clase que extiende de JPanel. La clase implementa un ComboBox con los posibles valores de escala, además escucha un evento para mostrar en primera instancia el valor actual de las escala, es decir, el primer valor que muestra en el campo del ComboBox es el valor de la escala actual de la imágen. Este valor es capturado mediante un listener.

Ejemplo de ComboScale lo encontramos en la ventana principal de gvSIG cuando tenemos cargada una capa y se utiliza para mostrar la escala a la que se muestra la imagen. Cuando seleccionamos un valor de escala en el ComboBox se redibuja la imágen con el nuevo valor.

Se adjuntan imágenes tanto de la utilización del ComboScale en una aplicación independiente de test y su uso dentro de gvSIG.

Aparece, en el programa de test, el valor actual de la escala.

Aparece, en el programa de test, el ComboBox desplegado con los posibles valores para la escala.

Ejemplo de uso en gvSIG con el valor actual de escala.

Ejemplo de uso en gvSIG con el ComboBox desplegado con los valores de escala.

A continuación se muestran fragmentos de código de cómo utilizar esta aplicación

Constructor de la clase

ComboScale cs = new ComboScale();

Creamos un vector con los elementos que deseamos tenga la escala y lo incluimos en el ComboScale

long[] scale=new long[5];
scale[0]=100;
scale[1]=500;
scale[2]=1000;
scale[3]=5000;
scale[4]=10000;
cs.setItems(scale);

Establecemos el valor que queremos que muestre el ComboScale en su campo de texto

cs.setScale(400);

Añadimos el ComboScale al panel

frame.getContentPane().add(cs);

Se ha añadido un botón adicional que establecerá el valor que mostrará el ComboScale en "500" cuando sea pulsado. El código necesario para realizar esa acción es el siguiente. Primero el contructor del botón ,luego las acciones que realizará y por último el código para incluirlo en el panel

JButton btn = new JButton();  //Creamos el botón
btn.addActionListener(new ActionListener(){   //Listener que espera la acción de pulsar el botón              
      public void actionPerformed(java.awt.event.ActionEvent e) {
              cs.setScale(500);    //Establece 500 como valor a mostrar en el campo de escala
              }
      }
);
frame.getContentPane().add(btn);  //añadimos el botón al panel

Esta clase extiende de JPanel. El objetivo de esta clase es implementar una herramienta que permita desplegar un ComboBox y que los items que aparezacan sean botones capaces de realizar acciones que previamente se les haya asignado. Una vez pulsado el botón deseado se mostrará en el ComboButton la imágen asociada a ese botón (si ha sido asociado por el desarrollador) o el texto informativo de la acción que implenta el botón.

En la siguientes imágenes se muestra un ejemplo de la utilización de esta clase.

Aparece el estado inicial del ComboButton del ejemplo.

Aparece el ComboButton desplegado.

Se muestra el ComboButton con el estado cambiado.

A continuación se incluyen el código explicativo de como utilizar esta clase.

El constructor

ComboButton cb=new ComboButton();

Se crean dos iconos para mostrar con los botones del ComboButton

ImageIcon icon1=new ImageIcon("images/backward.png");
ImageIcon icon2=new ImageIcon("images/forward.png");

Los constructores de los dos botones que incluye el ComboButton. A los constructores se les llama con los iconos creados

JButton b1=new JButton(icon1);
JButton b2=new JButton(icon2);

Las acciones que realizarán los botones cuando sean pulsados

b1.addActionListener(new ActionListener() {
      public void actionPerformed(ActionEvent arg0) {
              System.out.println("Pulsando el botón 1");
              System.out.println("Action command: "+arg0.getActionCommand());
              }
      }
);
b1.setActionCommand("action1");

b2.addActionListener(new ActionListener() {
      public void actionPerformed(ActionEvent arg0) {
              System.out.println("Pulsando el botón 2");
              System.out.println("Action command: "+arg0.getActionCommand());
              }
      }
);
b2.setActionCommand("action2");