Versión Previa

Adaptar JComboBox implicaba conocer cómo estaba implementado.

El siguiente diagrama muestra una simplificacion de la implementación del componente Swing JComboBox en Java 1.5, según el patrón MVC. Se ha destacado aquello más sensible a cambiar con la nueva versión o que concentra gran cantidad de la lógica del componente:

Diagrama 1: diagrama de clases simplificado de la versión de JComboBox de Java 1.5 . Se ha coloreado las clases que más van a cambiar en JComboBoxConfigurableLookUp.

Teníamos como clase principal: JComboBox, que contiene modelo, vista, y control:

• El modelo estaba claramente separado en la clase DefaultComboBoxModel .
• La vista, tiene un control propio, y, en combinación, la lógica de ambos está repartida en distintos componentes y clases:
  • Un ComboEditor con un JTextField interno, que mostrará el ítem seleccionado, y que, en caso que esté en modo editable, permitirá escribir texto.
  • Un JButton para mostrar/ocultar un popup con ítems que contiene el componente.
  • Un ComboPopup, que es de tipo JPopupMenu, y que contiene una JList (lista) en un JScrollPane, con los ítems renderizados por objetos de tipo ListCellRenderer.

La mayor parte de la lógica de la vista y el control asociado, incluido el de interacción con el usuario está concentrado en BasicComboBoxUI, que en Linux, por defecto es MetalComboBoxUI, mientras que en Windows es WindowsComboBoxUI.

• El control entre vista y modelo está concentrado en gran medida en la clase JComboBox.

Requisitos para la Nueva Versión

• Compatible con JComboBox.
• Que sea un Java Bean y siga el patrón software utilizado en Swing para este tipo de componentes: Modelo - Vista - Controlador.
• Poder listar los ítems que coincidan con el texto escrito, según un criterio determinado. SOLUCIÓN: poder establecer un agente con una búsqueda personalizada.
• La búsqueda por defecto: todos lo ítems del modelo que comiencen por el texto escrito.
• Que sea configurable. SOLUCIÓN: flags para los parámetros de configuración.
• Listar siempre todos lo ítems, o solo aquellos que coincidan con el texto, según el criterio de búsqueda. (Flag del modelo).
• Con o sin distinción mayúsculas / minúsculas en la comparación de ítems. (Flag del modelo).
• Establecer el idioma del que se utilizarán las reglas para ordenar y buscar los ítems del modelo. (Parámetro del modelo).
• Que se pueda habilitar / deshabilitar el que se muestre el popup. Esto es muy útil para evitar la interferencia con algún otro popup de la GUI de la aplicación, que se vea perjudicada cuando se selecciona por código algún ítem del combo.
• Que soporte comportamientos básicos. SOLUCIÓN:
  • Texto en rojo cuando no hay ningún ítem que coincida con el texto, según el criterio de búsqueda. (Flag del control).
  • Forzar a seleccionar un ítem. (Flag del control).
  • Sonido de beep cuando no hay ningún ítem que coincida con el texto, según el criterio de búsqueda. (Flag del control).
  • Forzar a que se oculte el popup cuando no haya ningún ítem que coincida con el texto, según el criterio de búsqueda. (Flag del control).
  • En caso que se muestren solo las coincidencias, que al pulsar el arrow button, se listen todos los ítems existentes en el modelo. (Flag del control y vista).
  • Completar el campo de texto con el ítem seleccionado en el popup vía las teclas up o down. (Flag del control y vista).
• Que se puedan listar los ítems de 3 modos posibles. (Parámetro del modelo) :
  • En el mismo orden en que están en el modelo.
  • En el mismo orden en que los devuelve el ''agente de búsqueda''.
  • Ordenados alfabéticamente (ordena siempre, aunque el ''agente de búsqueda'' ya los haya devuelto ordenados).

Hacia la Nueva Versión

El hecho que el modelo estuviese claramente separdado y concentrado en una clase, facilitó su adaptación. Después de un análisis con algunas pruebas se decició que debería de crearse uno nuevo, dado que costaría menos trabajo y nos evitaríamos posibles bugs por ejecución de código innecesario o incorrecto, en casos particulares. Así, como modelo, teniendo en cuenta el desarrollo existente, y los requisitos de configuración, se creó la clase DefaultComboBoxConfigurableLookUpModel .

Para el caso de vista y control, la adaptación era mucho más compleja. La clase principal, JComboBox implementaba parte del control entre vista y modelo, mientras que el resto de control estaba fragmentado con distinto grano, en múltiples clases relativas a la vista. Esta fragmentación en gran medida controlaba la interacción del usuario con el componente y sus sub-componentes.

Así pues, reimplementar vista y control permitiría tener un componente mejor adaptado, a cambio de un coste de desarrollo muy elevado. Por ello, como solución intermedia se decidió que la clase principal del nuevo componente, JComboBoxConfigurableLookUp, heredara de JComboBox, y actuase como una capa de adaptación entre el modelo, interacción de usuario y de programador, con la implementación existente de JComboBox, teniendo en cuenta la funcionalidad nueva que se quería agregar.

Implementar una capa de adaptación reduce costes temporales, a cambio de aumentar la de complejidad. Aumenta la complejidad debido a que, para realizar cualquier cambio, se debe de conocer la implementación existente, el órden de ejecución de instrucciones, lo que se quiere hacer. En este caso, la dificultad aumenta debido a que, al ser configurable, existen múltiples comportamientos distintos que se deben ofrecer, manteniendo los criterios de interacción (por desarrollador, usuario, u otros componentes o clases de Java) con el componente, en cualquier configuración. Esto no acabará de ser cierto, debido a que ciertas configuraciones, requerirán modos de interacción distintos, aún así, se debe de ofrecer un modo de interacción lo más uniforme y equivalente posible al que ya existía con JComboBox.

Uno de los requisitos más solicitados por los desarrolladores, y que hace que el componente sea muy útil, es el poder desarrollar búsquedas con unos criterios determinados, de modo que los ítems que se muestren o que se seleccionen sean aquellos que cumplan dichos criterios. Estamos pues trabajando en el nivel del modelo. La solución que se adoptó era que se crease una clase que implementase ILookUp, de modo que el modelo invocase a un objeto agente de dicha clase, y trabajase con el subconjunto se ítems que devolviese el agente. Para ello se le indicaba los ítems del modelo, el texto escrito por el usuario, el idioma, y si realiza o no distinción de mayúsculas / minúsculas. Los dos últimos parámetros vienen embebidos en un objeto StringComparator que permite realizar la comparación de ítems según dichos valores.

Nueva Versión

El diagrama 2 muestra los elementos implicados en la adaptación de JComboBox al nuevo componente.

Diagrama 2: diagrama de clases simplificado de la implementación de JComboBoxConfigurableLookUp. Se ha resaltado las clases nuevas, reimplementadas, o aquellas que tienen un peso muy importante en la lógica del nuevo componente, en comparación con JComboBox.

Vista y Control:

Teniendo en cuenta que será editable, para poder agregar control al perder foco, o al cambiar el texto, se agregan 2 listenes especializados (de tipo FocusListener, y KeyListener), al objeto de tipo JTextComponent contenido en el ComboEditor del componente.

Para poder controlar el popup, se agregó un listener especializado de tipo PopupMenuListener, a dicho componente interno.

Para poder controlar la pulsación de arrow-button, sí, el botón situado a la derecha con una flecha indicando hacia abajo, se agregó un MouseListener a dicho componente.

Por último, la parte de control más delicada es la que gestiona el documento donde se escribe texto. Este era uno de los puntos críticos debido a que las tres capas se veían implicadas: vista, control, y modelo. Para que se comportase según la configuración establecida, se creó una clase PlainDocumentTextFormatter, que hereda de la que existía previamente, PlainDocument, y enmascara el control atípico de este nuevo componente, invocando los métodos del padre según una nueva lógica. Será dicho documento el que se encargue además de actualizar el color del texto, y del sonido beep.

Modelo:

Como ya se ha explicado, el modelo ha debido de reimplementarse completamente, de modo que no es compatible con DefaultComboBoxConfigurableLookUpModel.

Se mantiene separado de vista y control, delegando la obtención de la sublista de ítems a un agente de búsquedas especializado, y limitándose a aplicar, según sea su configuración, un control sobre la ordenación de ítems, y el modo en que se le pasan a la parte de control y vista, o, sobre el método del agente a invocar, teniendo en cuenta la distinción o no de minúsculas / mayúsculas.

Internamente, para poder comparar ítems teniendo en cuenta las reglas de ordenación de un idioma en particular, así como la distinción mayúsculas / minúsculas, se utiliza un objeto de tipo StringComparator, con un objeto de tipo Collator, que será en última instancia el que realizará la comparación según las reglas del idioma establecido.

Los ítems dentro del modelo se almacenan según lo haría DefaultComboBoxModel, y, también de un modo ordenado (vía StringComparator), para acelerar el tiempo de respuesta.

Los ítems a los que se accederá, seguirán un criterio de posición según el valor de ItemsOrder y de ShowAllItemsInListBox. En caso que fuese necesario siempre se podrá acceder a todos lo ítems del modelo, por ejemplo: Vector datos = obj_modelo.getData();

El agente que utiliza por defecto realiza una búsqueda de todos los ítems que comienzan por un texto dado, este agente está implementado como StartsWithLookUpAgent. Cabe la posibilidad de cambiar de agente, para ello véase el apartado ¿Cómo crear mi propio agente de búsquedas personalizadas? . Se ha visto la necesidad de permitir habilitar / deshabilitar la notificación de eventos del modelo, para que desde un agente se pueda cambiar los ítems que contiene.

La siguiente tabla lista métodos públicos específicos del modelo DefaultComboBoxConfigurableLookUpModel, que no existen en DefaultComboBoxModel:

Para desarrolladores

Ubicado en el paquete org.gui.beans.comboboxconfigurablelookup.programmertests del directorio src-test-ui en el proyecto libUIComponent.

Básicamente es una clase, TestJComboBoxConfigurableLookUp, que instancia un objeto de tipo JComboBoxConfigurableLookUp, agregándole ítems, colocándolo en un JFrame, y visualizándolo. En dicho fichero hay abundante código, que una vez descomentado, podemos testear configuración, métodos, cambio componentes, etc.

En el mismo paquete hay un agente de búsquedas de ejemplo, SampleAgent, que devuelve los ítems ubicados en posición par; y un ejemplo de renderer de las celdas del popup, SampleBasicComboBoxRenderer, que cambia el color de fondo de la celda según una fórmula basada en en su posición, y que la pone gris si la celda está seleccionada.

Para usuarios

Ubicado en el paquete org.gui.beans.comboboxconfigurablelookup.usertests del directorio src-test-ui en el proyecto libUIComponent.

Es una pequeña aplicación, JFrameUserTestOfJComboBoxConfigurableLookUp, que permite crear instancias de JComboBoxConfigurableLookUp con distinta configuración, y testear y comparar su comportamiento.

La siguiente captura es de la interfaz de la aplicación:

Captura 1: GUI de la aplicación para testear el componente.

Permite seleccionar el constructor a utilizar para instanciar el componente en un JFrame (visible), definir los parámetros de configuración, rellenar con datos los ejemplos seleccionados, en la pestaña "Log" muestra las operaciones que se van haciendo, y cualquier excepción que se pueda producir, y permite incluso invocar algunos métodos públicos (vía el botón "Test"). Para esto último tiene un parser sencillo para un conjunto de parámetros que se le pueden pasar a los métodos. Con el botón "Ayuda" se muestra la explicación de los parámetros.

Con el botón "Resear" izquierdo restaura la configuración a la que viene por defecto en el componente, mientras que el derecho borra todas las instancias que pudieran haber.