Templates

[chous <chous@xxxxxxxxxx>]

Hola,

En un proyecto en el que llevo tiempo trabajando se lleva a cabo mucha 
generación de código [1], principalmente Java. Dicha generación se basa en 
componer "esqueletos" fijos (plantilla), y aplicar la información "dinámica", 
o los parámetros de cada plantilla. No hay nada novedoso que resaltar.
Cada plantilla en sí utiliza la sintaxis de java.text.MessageFormat ({i}: 
i-ésimo parámetro), si bien la composición se da en varios niveles, de forma 
que un parámetro concreto puede ser el resultado de transformar una 
determinada subplantilla. El proyecto no utiliza ningún algoritmo recursivo: 
cada plantilla incorpora la lógica particular necesaria para realizar la 
generación de código.
En el desarrollo del mismo, siempre he creído conveniente incorporar un modelo 
que represente mejor la problemática de generación de código a la que me 
enfrentaba, pero no tenía clara una solución, y tampoco la veía en ningún 
otro proyecto. La evolución de los lenguajes de plantillas lo ilustra: mismos 
conceptos, distintas sintaxis. Desde la separación estricta de lógica y 
contenido de XSL, hasta la mezcla más (opcionalmente) radical en JSP y 
similares. Daba la impresión que la idea de "flexibilidad" era más tangible y 
de mayor peso que cualquier otra consideración. No quiero hablar de JSP, por 
ahora :).

Después de esta introducción, vayamos al meollo. He encontrado un mecanismo 
que me resulta más adecuado que el que he venido aplicando, y que no sigue la 
linea de los lenguajes de plantillas, sino la teoría de compiladores y 
gramáticas (seguramente debido a que por fin he conseguido aprender a 
utilizar ANTLR [2]).
Si partimos del resultado final generado a partir de una plantilla, en lo que 
a ésta se refiere, cada parte del resultado está asociada a la transformación 
de una parte fija junto con un conjunto de datos, que se componen en 
secuencia para dar lugar al texto completo. Dichas partes fijas también 
serán, o podrán ser, resultado de otra transformación previa, a partir de 
otro texto fijo, y otro conjunto de datos. Tenemos por tanto una estructura 
de árbol, que podría ser inferida a posteriori, y que sería el resultado de 
un parseador que tuviera que procesar dicho resultado.
En ANTLR, dicho árbol se obtiene después de aplicar el analizador sintáctico, 
léxico y el parseador de árbol (tree parser), con la particularidad de que su 
topología está totalmente adaptada a las necesidades concretas de la 
aplicación, pudiéndo incluso incluir lógica explícita en la creación de dicho 
árbol. Una vez creado en forma de AST (Abstract syntax tree), bien se 
recorre, o bien ya ha sido indirectamente procesado por dicha lógica.

En el caso de la generación de código (o texto) a partir de plantillas, el 
marco es similar, pero inverso. Si partiéramos del árbol AST, al recorrer 
cada nodo se podría realizar la transformación de los parámetros, para 
obtener el texto final. Para construir el árbol, se podría pensar en partir 
de un XML (por ser jerárquico) con los "esqueletos" y sus relaciones. También 
podríamos necesitar algunos metadatos, como cardinalidades, "callbacks" 
específicos (por ejemplo, para tratar diferentemente elementos pares o 
impares de un bucle), elementos separadores (comas, etc.), y, por supuesto, 
cómo obtener los parámetros o datos "dinámicos".
Un mecanismo como éste tendría la ventaja de la flexibilidad, al externalizar 
las plantillas (no sólo las partes fijas, sino también su composición), sin 
sacrificar la posibilidad de incluir lógica específica necesaria para los 
casos particulares, y todo ello con sintaxis homogéneas (DTDs para las 
plantillas, y Java para la lógica), y separadas.

Se agradecen comentarios, críticas, dudas, etc.

Un saludo,
Jose.

[1] http://www.codegeneration.net/
[2] http://antlr.org