En los dos artículos anteriores repasamos de forma amable el esquema que anida tras Castanet: ya saben, transmisores, repetidores y sintonizadores, capaces de emitir y recibir algo más que applets, y además de una forma efectiva. Ese "algo más" encuentra su sentido en las presentaciones gráficas creadas con Bongo, una herramienta Java de composición de GUIs que hace buenas migas con Castanet (no en vano ambas son de la misma compañía: Marimba).

BONGO

Como afirma el folleto de Marimba, que es casi un bolero, "Bongo es un constructor de interfaces visuales para Java". En realidad, como el lector ya sabe (Payne dixit), Bongo fue el primer producto de Marimba, que fue relegado por su impracticidad y que, tras el relativo éxito de Castanet, fue nuevamente retomado por la compañía. El primer abandono estaba cantado: ¿Cómo va a comprar algún programador prudente un kit de desarrollo gráfico en Java que no puede trabajar en red, porque las bibliotecas Bongo necesitan ser instaladas, mantenidas y ocasionalmente actualizadas en cada cliente? ¿Cómo? Pues muy difícilmente, sobre todo teniendo en cuenta que existen, y cada vez existen más, bibliotecas gráficas Java, aparte de los kits de Netscape y compañía, que se aseguran al menos su instalación donde quiera que se instale uno de sus paginadores. Pues bien, si el primer abandono fue musicalmente inevitable, la revampirización de Bongo, tras Castanet, era previsiblemente sinfónica: si el problema de Bongo es la distribución y Castanet soluciona, de forma general, tal problema, ¿por qué un programador no va a desear este conjunto de caramelos de colores que, además, es Castanet-aware? Humm, la mercadotecnia lo puede todo. Así que los interfaces gráficos de usuario construidos con Bongo pasaron a denominarse "presentaciones" (y es que no basta con distinguir la herramienta y los componentes: hay que resaltar la especial calidad del producto final). Pero antes de seguir, lo mejor será que echemos un vistazo a una buena parte de los objetos gráficos que aporta Bongo:

PRESENTACIONES

¡Vaya! No quisiera haber parecido banal, pero es que Bongo es así. Aunque hay que notar que las presentaciones no son sólo dibujitos: los widgets han de configurarse (altura, ancho, tipo de letra, situación, etc.), y además, incluso en los interfaces es necesario algún código de enlace de widgets, de disparo de eventos, de ejecución de acciones. De hecho, una presentación Bongo es "una colección de elementos visuales, sus propiedades y cualesquiera scripts asociados". La misma ventana principal de Bongo, con dos pestañas, permite en la tanto cambiar de forma dinámica las propiedades del elemento seleccionado en la presentación, en estado de creación o modificación, como añadir código Java relacionado con el elemento seleccionado:

El estilo de trabajo es sencillo: cuando se abre o se crea una nueva presentación, aparece una ventana, separada de la ventana principal de Bongo, que sirve como parrilla de composición. Tal parrilla posee dos modos: edición y prueba, y el usuario puede cambiar entre ellos mediante secuencias de teclas o por el menú, de manera que la validación práctica de lo compuesto es inmediata (realmente lo es: cada vez que se realiza un cambio en la presentación, Bongo lo compila en una hebra aparte, de forma que cuando queremos probar el funcionamiento del interfaz no hay trabajo de compilación que hacer). Toda presentación consta de una ventana-marco principal sobre la que se añaden elementos, en tantas capas como queramos, mediante menús dinámicos. Cuando nos encontramos en modo de prueba, la ventana principal de Bongo aparece sin funcionalidad, pero cuando pasamos a modo de edición, tal ventana-monitor refleja un diálogo con las propiedades del elemento seleccionado en la parrilla de composición de la presentación. Si cambiamos una propiedad (por ejemplo, el color de fondo de una lista desplegable) y pulsamos "apply", el cambio se apreciará inmediatamente en la parrilla de edición. Por otra parte, si hacemos click en un elemento en la parrilla y seleccionamos en la ventana principal Bongo la pestaña de "Script", podremos introducir código Java que se asociará al elemento gráfico seleccionado, permitiéndonos interactuar con otros widgets y dotar, por tanto, de alguna funcionalidad a la presentación. Pero así como las hojas de propiedades están bien (en gran medida por la versatilidad de los widgets Bongo, que acumulan más propiedades de lo habitual), el editor de scripts Java es penoso: o sea, es una simple TextBox. Punto. Sin menúes de edición, sin... En fin, sin nada más que un espacio en blanco donde escribir. Y es que, claro, se supone que poca inteligencia puede haber en una presentación. En cuanto a los posibles errores de compilación... aparecen en la consola Java, claro:

Pero si al lector le han parecido editor de código y consola francamente insuficientes para cualquier aplicación seria, es porque lo son. Me explico: Bongo es un mero constructor visual que necesita de un entorno con capacidades avanzadas de edición de código Java, depuradores, compiladores JIT, etc., de manera que, en la práctica, para cualquier cometido no trivial necesitaría de Symantec Visual Café, IBM VisualAge for Java o algún otro entorno Java similar (siempre que se utilice la máquina virtual Java estándar, condición sine qua non para que Bongo funcione). Y es que las presentaciones Bongo son, al final, código Java que utiliza las bibliotecas gráficas provistas por Marimba, de forma que, por ejemplo, podría optimizarse su ejecución compilándolo en código nativo con algún compilador Just-in-Time comercial, como el de Symantec.

POSIBILIDADES DINÁMICAS

Los típicos árboles de componentes pueden, con Bongo, contener texto, botones, listas que a su vez contienen árboles, gráficos, etc. Y es que con la ayuda de Bongo se pueden implementar con cierta facilidad características que hasta hace poco eran exclusivas de lenguajes dinámicos como Smalltalk, como la inserción en un contenedor o lista de cualquier objeto de la colección gráfica de la biblioteca, o la inserción también, en un típico elemento gráfico de manejo de tablas, de componentes de sonido, listas, botones, enlaces web, gráficos, texto, etc., como podemos ver en:

INTEGRACIÓN BONGO-CASTANET

Como vemos en la figura siguiente, la integración de Bongo con Castanet es perfecta. En lugar de convertir un applet (con sus limitadas capacidades visuales, basadas en la parca AWT) en un canal, una presentación es directamente un canal, por lo que puede ser distribuida por Internet/Intranet y mantenida actualizada sin esfuerzo adicional alguno (de la carga y actualización de los componentes básicos, biblioteca o run-time, se encargaría el mismo sintonizador). De hecho esta integración provee a Bongo de inmejorables características para el trabajo en equipo de programación de interfaces: sobre la base de una presentación "master" se aplicarían referencias a "subpresentaciones", que se repartirían a programadores geográficamente dispersos, de manera que los cambios serían propagados a todo el equipo mediante el sistema de distribución de Castanet.

CRÍTICA

Se ha inundado al lector con gráficos y patrones de colores, con posibilidades de distribución y con la supuesta facilidad de construcción de interfaces: con Java hecho fácil, en definitiva. Pero esto no es así. De hecho, tanto fasto exterior me recuerda a la princesa de Riquete el del Copete. Veamos los puntos flacos de Bongo (que ahora perderá algo de resonancia, vamos):

• El esquema de distribución de trabajo en equipo únicamente se ocupa de mantener la imagen de todos los integrantes sincronizada, así que permanece a años luz de entornos serios de trabajo cooperativo, como Envy/Developer y otros.
• Bongo, con un precio actual de $495, dobla a entornos completos de desarrollo e iguala a otros, como Visual Café, con grandes posibilidades visuales y un magnífico IDE subyacente. Quiero decir: ¿Realmente necesito tanta facilidad por tanto precio? Claro que si uno no quiere codificar por sí mismo un control arbóreo, tendrá que comprar alguna biblioteca de controles Java, que podría ser Bongo, o también Jwidgets de Rogue Wave o cualquier otra similar.
• Bongo no soporta actualmente el modelo de componentes de Java Beans, aunque se ha anunciado el próximo completo soporte. Quedamos, de nuevo, en espera (si el lector piensa que tal soporte no es muy importante, debiera reparar en que Bongo tampoco soporta ActiveX).
• La integración de Bongo con otros entornos de desarrollo Java es tanto mejor cuanto peor es el entorno destino de la integración. Entiendo que la compenetración será perfecta con herramientas shareware como Kawa, pero que Bongo tendrá problemas y dificultades para competir con entornos de desarrollo visual Java sofisticado como IBM VisualAge for Java, con su propio esquema de relaciones, de creación de código, etc. Claro que siempre queda la posibilidad de utilizar las herramientas desde la línea de comandos, aunque esto suena como silencioso fin para tan sonoro principio.
• Pese a que pueden usarse widgets representativos de tablas, Bongo no proporciona facilidades de programación visual para el acceso a bases de datos, singularmente mediante JDBC, de manera que tendremos un bonito interfaz con una manual codificación interna.
• Bongo se basa en la reutilización de componentes, pero la metáfora de las presentaciones es demasiado restrictiva, toda vez que impide la codificación de interfaces en modelos de roles, patrones de interfaces, etc.
• La construcción de interfaces gráficos con una herramienta distinta de la usada para la codificación del modelo de objetos (también llamado "capa de objetos de negocio") y para el filtro de acceso a bases de datos originará un desajuste organizativo y productivo difícil de manejar. A no ser que se trate de una aplicación trivial. Claro que entonces incluso hasta se podrían utilizar... ¡Applets!
• Parece que el éxito, cada vez más evidente, de Castanet debiera también arrastrar a su hermano menor, Bongo, a la difusión masiva. Pero no es así. Personalmente dudo que Bongo, con su actual filosofía de trabajo, se imponga en el mercado como producto estrella de desarrollo Java (aun en la parte de interfaces).

Con todo he de notar que Bongo resulta perfecto para el usuario distraído que, no queriendo entrar a fondo en las cuitas del lenguaje Java ni en Internet, quiera crear diálogos impactantes en poco tiempo y con ciertas garantías de funcionamiento. Y eso sin olvidar la integración con Shockwave y otros productos afamados. Pero, vaya, quizás esto haya sido la última crítica.