Después de buscar un poco he encontrado una librerí­a para leer xmls que si que parece funcionar.

LIBXML2F90 lee los tags y va almacenando la información en una estructura arbórea. Mediante unas funciones de la librerí­a se puede ir avanzando por la estructura y comprobando los nombres y atributos de los tags.

Eso si, tuve que trucarla un poco para que funcione en el Compaq Visual Fortran (CVF). Debe ser un problema del sistema operativo (Windows siempre fastidiando) porque la misma sentencia funciona correctamente en un programa de prueba. Para los que les interese, es un read(unidad, fmt=’(a)’, advance=’no’, size=tam), y el advance no le gusta al CFV en ese contexto.

Entre hoy y ayer en el trabajo he estado utilizando el patrón de diseño Visitor. Es mi primer encuentro directo con un patrón de la banda de los cuatro (GoF o Gang of Four), y mira que estuve pensando la solución un buen rato hasta que mi jefe me contó lo del patrón en cuestión, que explicaré brevemente a continuación.

El patron Visitor se utiliza cuando existe una clase padre A y una o varias clases hijas A1, A2, …, AN; todas tienen un metodo comun, por ejemplo metodo1() que realiza diferentes tareas dependiendo del tipo de la clase. ¿Para quá puede servir esto? Pues para iterar por una lista de clases A e hijas y llamar al metodo1 en cada clase.
El problema surge en que para recorrer la lista, el tipo del objeto (item) en cada iteracion debe ser de tipo A (el padre), y que si se llama a item.metodo1() ¡se ejecutara el metodo1 contenido en la clase padre! En lugar de lo correcto, que serí­a ejecutar el metodo1 de la clase hija a la que pertenezca el item.

La solucion consiste en crear un metodo accept(VisitanteA visitante) en todas las clases A e hijas que acepte un “visitante” (una clase de tipo VisitanteA). En el metodo accept se llama al método visit de la clase visitante que se paso como parametro, y el unico parametro del método visit es “this”, un puntero al objeto actual.

En la clase VisitanteA se implementa un método visit(A param), otro visit(A1 param), otro visit(A2, param), etc. Uno por cada clase que se quiera “visitar”. En ese método visit(Ax param) es dónde se ejecuta la lógica de nuestro antiguo método1(). De este modo, el Visitante “descubre” la clase del objeto, ya que el objeto se enví­a a si mismo y debido a la sobrecarga del método visit() se ejecutan las sentencias correctas.

Espero haberlo explicado medianamente bien. Por el momento he implementado como 4 o 5 clases visitantes. Tengo muchas herencias inusuales y restricciones semánticas en la base de datos que requieren del patrón. Todo esto me pasa por “mover” el modelo a la base de datos, en lugar de implementarlo en la lógica de negocio. Sin embargo, considero que este enfoque es mejor y más mantenible, aunque más laborioso. En fin, veremos como acaba el proyecto.

Comentaré en el post algunas de mis impresiones al integrar Fortran y XML, y de como he decidido dejarlo de lado.

En primer lugar citaré las direcciones web de las 3 librerí­as de parsers de XML para Fortran mas populares.

• xml-fortran
• xmlf90
• Parser xml sin nombre

Probé el primero de los tres pensando que leer los datos que querí­a de mi fichero XML serí­a un proceso straight-forward (como me gusta esta expresion). Pues me equivoque: hace falta declarar metodos especificos para manejar cada tag, de modo que la conversion es hasta cierto punto manual.
Asi que desistí­ y me metí­ con el XSLT a ver que pasaba. El proceso es: 1) El usuario define las opciones y las guarda en un fichero XML, 2) Se le pasa una hoja de estilos XSLT que convierte del XML a un fichero de texto plano con numeros y una estructura prefijada, 3) Se lee desde Fortran de forma facil.
La verdad es que me duele hacerlo así­, tiene que haber cosas mejores.

Mirando el segundo de los parsers, esta en un estado mucho mas avanzado que el anterior. Tendre que probarlo antes de decidirme a usar XSLT (me duele, y mucho).

La verdad es que esto del XML es de un pijerí­a impresionante. En vez de tener un fichero simple con los valores numericos y las opciones representadas con enteros, tenemos una estructura arbórea de datos interrelacionados. La verdad es que no se si me va a compensar el trabajo extra, pero casi seguro que me comensará, ya que el XML es una herramienta actual y muy extensible, cuya utilización en el ámbito al que me atengo está todaví­a en sus inicios. Veremos que pasa con el segundo parser…