La cuestión es: ¿Necesito realmente Java para Internet? Es decir: dado que Java no es sino a la vez un subconjunto y batiburrillo de cualidades de otros lenguajes, ¿no podríamos usar un lenguaje pretendidamente “serio” con otro subconjunto de tales cualidades para las cuitas de Internet, prescindiendo así de Java? La respuesta es … ¡No! “¿No?” -exclamará algún self-made lector- “¿Cómo que no?” ¡Ah, caro lector, es que, cuando menos, ya no podemos prescindir de los applets! Lo cierto, y esto resulta evidente para cualquiera que acceda aún mínimamente a Internet, es que Java ha impregnado el contenido [1] de la información que por allí se encuentra o pulula: los applets, la interacción con visores con capacidades Java, los esquemas de composición de Java Beans con el resto del universo y la difusa idea que Java es, a la vez, el vehículo y los ocupantes, configuran una visión de Internet en la que Java es imprescindible. Y es que el planteamiento es parecido al que nos enfrenta a realidades incontestables cuando intentamos abordar el almacenamiento y recuperación de datos: ficheros POSIX, bases de datos relacionales, bases de objetos, etc.: es lo que hay. “Bien, bien: de acuerdo” -ruge el impaciente lector- “Java no puede obviarse. Vale ¿Y qué más?”. Oh, muchísimo más. Y es que, si Java existe, ¿por qué no integrarlo en los viejos sistemas [2]? Es decir, ¿por qué no tender hacia un modelo de integración de Java en otros lenguajes en vez de considerar Java como el punto de convergencia de los lenguajes en sí? O sea, ¿por qué no codificar en C++ y usar los recursos de Java cuando sea aconsejable o necesario? Y es que Java aún no es una dictadura (donde todo lo que no estuviera prohibido sería obligatorio, como reza el dicho anónimo). Claro que C++ necesita echar mano de bibliotecas, y lo que aquí mentamos suena demasiado grandilocuente: un enorme conjunto de clases que proporcione a C++ características para las que no fue diseñado, sin poder modificar el lenguaje en sí, de forma que se troque en el lenguaje natural de Internet. Oh, ciertamente, el objetivo es, por una cuestión de prudencia, simplemente inabordable. Otra cosa es que nos centremos en algunos aspectos sectoriales de Internet más asequibles. Vamos a dedicar, así, nuestro énfasis a las páginas web construidas en HTML.

WEB<TOOLKIT> TM

Una de las maldiciones de C++ fue su liberación en el mercado sin un conjunto apropiado de bibliotecas normalizadas [3], de forma que las cuitas multiplataforma, de construcción gráfica y otras -incluso de multi-enhebramiento-, han tenido más que ver con la pericia y disposición comercial de cada uno de los implementadores que con las verdaderas necesidades de los usuarios considerados como comunidad. Siguiendo con este enfoque de segmentación de posibles interfaces, inevitablemente ligado a la codificación en C++, he aquí la enésima biblioteca de clases que nos permitirá … ¡escribir páginas web usando C++! Pero, esperen, antes de abordar los aspectos técnicos permítanme relatarles mi aproximación a esta biblioteca, mis esperanzas guerrilleras, mis decepciones reales y mis posteriores sentimientos huxleyanos de felicidad.

ORGULLO Y PREJUICIO

Yo conocía a ObjectSpace Inc por el buen temprano trabajo que realizaron con la adaptación de la STL C++ en su producto STL<ToolKit> TM, que llegué a recomendar desde esta revista merced a la oportunidad y elegancia de sus algoritmos de ayuda. Naturalmente cuando supe de su nuevo producto dedicado a conceder a C++ parte de la funcionalidad tan anhelada en Internet, y además basado en su anterior implementación STL, inmediatamente les pedí una copia licenciada, con la que he estado trabajando durante algunos meses. La cuestión es que, y es ahí donde encuentra su sentido el título Austeniano, yo tenía las mismas expectativas que cuando cambié del cifrado al solfeo en guitarra, pues de muy joven llegué a pensar que el solfeo me haría entrar en otra dimensión interpretativa, cuando realmente sólo me hizo mejorar y afinar el tempo. ¡Ah, la ignorancia! Bien: pues resulta que el uso de Web<ToolKit> TM, acoplado al del compilador (en éste mi caso: Microsoft Visual C++ [4]), finalmente me causó una matizada desilusión, tras la cual pude realmente apreciar, como en el solfeo, la bondad de su enfoque. En primer lugar no se trata de una idea genial (y esto, visto el pasmo de Java, quizás sea una ventaja), sino de una extensión natural de ciertas bibliotecas C++. En segundo lugar: el entorno de uso de esta biblioteca es sentidamente distinto del que necesita de programación directa HTML. Finalmente, el producto cubre un hueco de integración difícilmente rellenable con otros lenguajes. Pero veamos en qué consiste exactamente este conjunto de clases, sobre las que el lector curioso puede encontrar información adicional en “http://www.objectspace.com”

EL ROSARIO COMERCIAL

Web<ToolKit> TM es una biblioteca de clases que facilita la codificación en C++ de programas CGI (Common Gateway Interface) y documentos HTML, con los siguientes beneficios:

• Reutilización : se pueden escribir programas CGI en C++, lo que posibilita el (re)uso directo de otras bibliotecas de clases C++, eliminando la necesidad de envolver tales clases mediante wrappers para su uso en scripts CGI.
• Simplicidad : Web<ToolKit> TM traduce a HTML transparentemente cualquier tipo de carácter o construcción sintáctica. O sea, no debemos preocuparnos por codificar “ñ” como “&ntilde;”, o “á” como “&aacute;” en HTML.
• Mantenimiento : teniendo en cuenta que podemos usar directamente C++ sustituyendo al scripting CGI, es claro que podemos usar, también, las facilidades de la Tecnología de Objetos para generar código y estructuras más fácilmente mantenibles.
• Detección de errores : la conversión de las construcciones C++ a HTML se modula por un conjunto de reglas o restricciones que pueden habilitarse, deshabilitarse o modificarse en tiempo de ejecución.
• Compatibilidad con los estándares : Web<ToolKit> TM se apoya directamente en la biblioteca estándar de plantillas (STL) de C++ (bien en la implementación de ObjectSpace, bien en cualquier implementación ajustada al estándar) y en la especificación ANSI/ISO de String. Esto asegura la transportabilidad y reduce las cuitas de mantenimiento.

CGI, APPLETS Y HTML

Como puede fácilmente apreciarse, las ventajas prometidas se segmentan en dos vertientes: por un lado se simplifica la creación y mantenimiento de programas CGI y por otro … “¡Eh, un momento!” -salta aquí el lector hiperinformado- “los scripts CGI tienden a desaparecer, sobre todo porque con los applets Java y …” ¡Alto, alto! De momento dudo mucho que la comunicación con los servidores vía CGI desaparezca, tal y como están actualmente las cosas (y obviaré aquí la discusión que incluye IIS y otras soluciones). Otra cuestión es que tales scripts sean codificados en Java o C++. Y, claro, esto es precisamente lo que nos ocupa.

Bueno, decía que siempre es ventajoso sustituir un lenguaje de puro script por otro lenguaje completo orientado-a-objetos (sea éste C++ o aun Java), con lo cual el beneficio deviene tangible. La otra genérica mejora se refiere a la codificación de documentos HTML. En realidad lo que hace Web<ToolKit> TM es embeber las construcciones típicas HTML en clases correspondientes, de manera que finalmente se genera puro código HTML. He aquí tal correspondencia básica:

Es evidente que la correspondencia de nombres es trivial (a excepción del prefijo “os_” que obedece al ánimo de evitar colisiones de nombres sin usar “namespaces”). Pero, ¿cómo enlazar todo esto con una página HTML? Pues mediante la clase “os_page”, que representa una página web (en este caso sin marcos). Se trata de crear (instanciar) un nuevo objeto de tipo os_page e ir añadiendo (insertando) secuencialmente los distintos objetos de las clases anteriormente expuestas, de tal manera que finalmente volcaremos el contenido de tal objeto os_page en un dispositivo de salida, y en tal vuelco el objeto os_page traducirá su contenido de objetos C++ a script HTML. Pero veamos un ejemplo.

CONCEPTOS BÁSICOS

La arquitectura de la biblioteca es prudentemente simple: todas las clases, a excepción de “os_form_map”, derivan de la clase “os_element”, que representa la unidad de composición. Incluso la clase “os_element_group”, base del manejo de los tipos agregados como listas, tablas, etc., deriva de “os_element” [5]. En cuanto a su uso, se basa en la inserción ordenada de tales elementos (os_element) en una página (os_page). Pero vayamos por partes. Lo primero es crear una “os_page” que represente la página web, y en este caso se aprovecha una sobrecarga del constructor para añadirle el título:

os_page miPagina( “Home Page de Zutano” );

Lo siguiente es insertar en la página recién creada distintos elementos (en este caso una línea de texto):

miPagina.add( “¡Puedo escribir directamente en español!: ” );

También podríamos haber usado, simplemente, la sobrecarga de operadores respecto de la clase os_page:

miPagina << os_text( “ÁÉÍÓÚÑáéíóú” );

o simplemente

miPagina << “ÁÉÍÓÚÑáéíóú”;

o quizás, usando de un identificador intermedio,

os_text elOrgulloNacional( “ÁÉÍÓÚÑáéíóú” );

miPagina << elOrgulloNacional;

toda vez que la función add(…) y el operador << respecto de os_page están sobrecargados para admitir, entre otras cosas, bien cadenas de caracteres bien elementos de texto (una especificidad de os_element). Hay que notar que cada cadena de las así insertadas se concatenará con la anterior en la forma

¡Puedo escribir directamente en español!: ÁÉÍÓÚÑáéíóú

pues para dotar de bloques y formato al texto habría que usar los os_elements apropiados (os_paragraph, etc.). Note de paso el lector la facilidad con que hemos codificado una frase con caracteres que requieren etiquetas no intuitivas en HTML.

Finalmente, para convertir todo lo anterior en código HTML, lo único que hay que hacer es volcar la página os_page en el objeto cout (see-out, para quien lo haya olvidado):

cout << miPagina;

Claro que, ¿cómo se compatibiliza este volcado con la generación de HTML desde un programa CGI? ¡Pues simplemente! La clase os_page contiene un enumerador:

enum output_type {

non_cgi; // la opción por defecto

cgi;

}

de forma que si cambiamos el tipo de salida a “cgi”, bien como último parámetro en cualquiera de los constructores de os_page, bien utilizando la función

os_page& output( output_type output )

a el stream de salida se le añadirá la etiqueta de contenido MIME siguiente “Content-Type: text/html”.

LA CONSABIDA PORCIÓN DE CÓDIGO

Vayamos con un ejemplo típico de texto informático [6], con el que se intentarán mostrar algunas de las capacidades de la biblioteca:

#include <iostream.h>

/* Se ha incluido el soporte básico de streams para entrada y salida, lo que permitirá usar la sobrecarga de operadores, y seguidamente se incluyen las cabeceras de las clases de Web<ToolKit> TM */

#include <ospace/web.h>

// la función main, pues se trata de un programa C++

int main( int, char** )

{

// Creamos nuestra página web

os_page miPaginaWeb( “Ejemplo de Juguete” );

// Añadimos un título de segundo nivel (de ahí el “ 2”),

// centrado entre los márgenes de la página

miPaginaWeb << os_center( os_heading( 2, “Mi Página” ) )

// y una línea divisoria (note el lector que la estamos

// insertando en el objeto de la línea anterior mediante

// la concatenación de operadores “<<”)

<< os_horizontal_rule()

// A continuación iniciamos un párrafo

<< os_paragraph( “Primer párrafo.” );

// Ahora creamos un párrafo más sofisticado

os_paragraph parrafo( “Vemos el texto enriquecido:” );

// tras esto se insertan en el nuevo párrafo rupturas de

// línea (os_break()) y texto en negrita y en cursiva

parrafo << os_break()

<< os_bold( “Me gustan las negritas” )

<< os_break()

<< os_cursive( “Odio a esa gente tan cursiva” );

// lo que falta es añadir el párrafo a la página web

miPaginaWeb << parrafo;

// y ahora sigue un hiper-enlace a otra página web

os_paragraph enlace( “¿Desea ver Maravillas?”);

enlace << os_text( “Visite ”)

<< os_hyperlink(

“http://www.well.com/user/ritchie/oo.html”,

“The Object Oriented Page” );

miPaginaWeb << enlace;

/* Naturalmente existen más posibilidades en la construcción de hiper-enlaces (como a los de la misma página, etc.) Finalmente hay que generar el código HTML */

cout << miPaginaWeb;

return 0;

}

C++ Y APPLETS JAVA

¿Cómo integrar applets Java en nuestra página? Pues tan fácilmente como se inserta un os_applet (derivado de os_element) en una os_page:

os_applet miApplet( “JackhammerDuke.class”, 300, 100);

miPaginaWeb << miApplet;

Como se ve, el primer parámetro del constructor de os_applet es el nombre del fichero de clase Java correspondiente (code), seguido por la longitud en pixels del ancho (width) y alto (height) de la zona en que se ejecutará el applet. Existe otro constructor que añade la URL base del applet (codebase). Respecto del alineamiento del applet se utiliza el enumerador “alignment”. Existen además funciones de establecimiento y lectura para cada uno de los parámetros ya reseñados y también para hspace (los pixels de espacio horizontal que bordean el applet) y vspace (lo mismo que hspace, pero referente al espacio vertical, claro).

¿Qué ocurre, con todo, con los parámetros que pudieran pasarse desde la página web al applet? Bueno, sólo necesitamos instanciar uno o más objetos de tipo os_parameter e insertarlos, de nuevo, en el os_applet correspondiente:

os_parameter parametro1( “Nombre1”, “Valor1” );

miApplet << parametro1 << os_parameter( “Nombre2”, “Valor2” );

Aquí vemos cómo se insertan dos parámetros en nuestro applet, de forma que cada uno de ellos está caracterizado en el correspondiente constructor por el nombre del atributo al que se pretende asignar el valor que le sigue.

¡ENVIDO Y YO!

Como el lector ya habrá podido adivinar, Web<ToolKit> TM incorpora muchas otras clases que, en la práctica, encapsulan el grueso de la funcionalidad necesitada para la creación y el mantenimiento de páginas web. Podemos hablar, así, del control de errores, que posibilita la visualización de errores HTML de forma consistente e independiente del visor web en cada caso utilizado; citar, también, las clases dedicadas a tablas y tablas anidadas, así como las que representan marcos que permiten segmentar el área de la página web en zonas de distintos tamaños porcentuales y posiciones relativas, a las que además se les puede asignar nombres y pueden ser asociadas al resultado de hiperenlaces (sobre todo para visualización de resultados); nombrar las clases dedicadas a la representación de elementos de formularios, como botones, campos de edición, cajas combo, etc. Cabría resaltar, también, una importante característica de la biblioteca: todas las clases, por el hecho de derivar, directa o indirectamente, de os_element heredan la función “key(String)”, que se usa para asignar un nombre a cualquier elemento a insertar en una página web. El sentido de esta asignación es permitir la aplicación de funciones de búsqueda y reemplazo sobre elementos de la página (mediante las funciones find_first(), find_all(), remove_first(), remove_all(), replace_first() y replace_all(), todas disponibles en cualquier clase derivada de os_element, y que usualmente devuelven un puntero al os_element o grupo de os_elements resultado de su aplicación), tal y como puede verse en el siguiente ejemplo:

os_text holaAustero( “¿Cómo está usted?”);

holaAustero.key( “hola” );

miPaginaWeb << holaAustero;

miPaginaWeb.replace_all( hola, “¡Es una placer verle de nuevo!” );

Naturalmente este enfoque tiene muchas más posibilidades: podríamos usar un vector STL para almacenar el resultado de la aplicación de la función “find_all( String key )” en una os_page, y luego iterar sobre ellos (con un iterador STL) para aplicar cualquier tipo de posicionamiento gráfico o procesamiento sintáctico. De hecho la posibilidad de nombrar elementos permitiría agrupar con una misma clave distintos contenidos de similar valor semántico, de manera que nos resultará mucho más fácil mantener la coherencia de nuestra página ante cambios y re-estructuraciones.

CONCLUSIONES

“Bueno, todo sonó muy lindo, pero ¿para qué demonios necesito yo esta biblioteca cuando ya dispongo de excelentes editores WYSIWYG para HTML?” -exclama el hirsuto lector ofimático. ¡Pues para programar, naturalmente! En definitiva se trata de C++, y esto sugiere que el fin de la biblioteca es ser usada en un entorno de desarrollo, no como mera herramienta de visualización sustitutiva de Java, como la metadona del caballo o el bourbon del escocés. En realidad esta herramienta es enormemente práctica para generar dinámicamente páginas web, como por ejemplo en una típica respuesta de un programa CGI, codificado mediante Web<ToolKit> TM, a un formulario de entrada en una página web, pues la página generada usualmente tiene que ver con la interacción del usuario respecto del formulario (por ejemplo: “le faltó su número de tarjeta VISA” u “olvidó su teléfono, señorita”). Piense el lector que el embebimiento de HTML en su código “usual” puede provocar más de un mareo, así que la idea de la continuidad C++ no suena en absoluto descabellada. Claro que … ¿esto mismo podría hacerse en Java? ¡Ciertamente! Pero eso es otra historia [7]…

REFERENCIAS DIRECTAS

• Web<ToolKit> TM User Guide and Reference Manual , ObjectSpace Inc, 1996, DOC-0100-03.
• STL<ToolKit> TM User’s Manual , ObjectSpace Inc, 1995, 290010.
• Design Patterns (The GOF book), Gamma, Helm, Johnson y Vlissides, 1995, Addison-Wesley, 0-201-63361-2.
• How to Talk Dirty and Influence People , Lenny Bruce, 1965, Playboy Press.

[1] Java es “el contenido incontinente”, si atendemos a Hal Fraiser. Claro que otra posibilidad sería aplicar a Java lo que Toddi pensaba del Esperanto: “un cóctel que se cree océano”. Ya ven, pura incontinencia.

[2] Se trata del enfoque “realista”. Uno puede dudar de un mundo básicamente homosexual, pero resulta difícil explicar por qué el ejercito norteamericano, por ejemplo, se niega a integrar en sus filas a lo que constituye una realidad social y humana que en absoluto puede obviarse. ¿Java y la homosexualidad? Bueno, no me negarán que la comparación tiene posibilidades (vamos, que tiene su “aquél” ;-)

[3] Esto, que yo encuentro tremendamente razonable, tiene multitud de detractores, y es una de las principales causas de la demora del estándar C++.

[4] Ya ven que no tengo empacho en utilizar todos los compiladores que se crucen en mi camino. Claro que cualquier otra estrategia distinta a este puro proxenetismo es delicadamente peligrosa. Recuerdo que en una reciente reunión y ante la pregunta “¿qué compilador recomienda?” aconsejé que se compraran todos, y … no, no me echaron a patadas.

[5] Se trata, en definitiva, del conocido esquema de glyphs de Calder, que mediante un patrón de composición permite representar estructuras sofisticadas en documentos. El lector interesado en un mayor detalle sobre esta estructura colaborativa de objetos puede revisar el patrón “Composite” del libro GOF de patrones de Diseño que se detalla en las referencias del artículo.

[6] El símil más cercano que jamas haya encontrado en relación a los ejemplos de juguete que aparecen en las obras informáticas es la definición de Freire de una modelo: “señorita que, por lo general, constituye un mal ejemplo”.

[7] Parafraseando a Lenny Bruce podría afirmarse que cuando alguien alcanza el poder una de sus primeras tareas es identificar (e incluso crear) una minoría a la que odiar. Definitivamente Java y C++ están en onda. ¿O era Sun y Microsoft?