El parseador y generador de diagramas del que hablábamos por acá ahora tiene nombre y está publicado como aplicación web en Google AppEngine:
NS-Matic .
Como se sabe, desde hace poco AppEngine soporta Java, y eso significa que soporta varios lenguajes más: todos aquellos que compilan a bytecode para la JVM. Lo que yo no sabía hasta luego del primer deploy, era que las limitaciones impuestas por Google iban a frustrar el plan. Resulta que hay una lista blanca de clases estándar disponibles, entre las cuales no están las de AWT. En AppEngine no se puede instanciar ninguna clase de AWT. Google provee un API alternativo de manipulación de imágenes pero no incluye el tipo de operaciones que mi aplicación necesitaba.
Al no poder generar imágenes en el servidor, consideré usar el viejo generador de HTML. Pero no me quise conformar, e investigué la posibilidad de pasarle el fardo al cliente: ¿se puede dibujar en el navegador?
Dojo al rescate
No estaba al tanto pero resulta que sí, todo navegador que se precie hoy en día tiene capacidad de gráficos vectoriales. La mayoría con SVG, Internet Explorer con VML (cuándo no, cortándose solo). Cómo será la cosa: se está hablando de que esto le vaya ganando terreno a Flash. Para resolver las diferencias entre navegadores, podemos usar una librería cross-browser como
Dojo Toolkit , y su módulo Gfx que sirve precisamente para graficar. En mis diagramas, el resultado se ve mejor que los GIF que generaba antes con AWT. Lo que se pierde es la posibilidad de guardar el diagrama como un archivo de imagen, lo que sería más práctico que guardar una página con javascript.
Antes dijimos que estábamos preparados para agregar nuevas implementaciones de generadores de diagramas porque teníamos un diseño extensible. El generador de AWT recorría el AST y daba como resultado un
BufferedImage; el nuevo debería recorrer el AST y retornar un
String con el script a ser ejecutado por el navegador.
Pero esto nos lleva a un nuevo replanteo: los generadores de AWT y Dojo Gfx, si bien apuntan a tecnologías diferentes (el
cómo), tienen un núcleo común: el
qué. Antes estábamos mezclando el
qué y el
cómo, ahora estamos obligados a extraer el
qué, si queremos hacer las cosas bien.
El graficador abstracto
La idea sería poder definir en abstracto qué líneas hay que trazar y qué texto hay que desplegar, y en qué posición. Para esto necesitamos un modelo sencillo para generadores de tipo gráfico, que tengan la capacidad de tomar esa especificación y ejecutarla en alguna tecnología.
trait Alignment
case class AlignLeft() extends Alignment
case class AlignCenter() extends Alignment
case class Pos(x:Int, y:Int) {
def shift(dx:Int, dy:Int) = Pos(x + dx, y + dy)
}
case class Line(from:Pos, to:Pos)
case class TextLine(text:String, anchor:Pos, align:Alignment)
Pos define una posición (
x,y), y con el método
shift obtenemos una nueva posición con un delta horizontal y otro vertical. El concepto de posición, y la posibilidad de obtener una a partir de otra preexistente, serán de uso intensivo en esta solución.
Line y
TextLine definen los dos elementos básicos que sirven para armar todo.
class GraphicElement(
val pos:Pos,
val width:Int,
val elemHeight:Int,
val textLines: List[TextLine],
val lines: List[Line],
val children: List[GraphicElement])
{
lazy val height: Int = maxY - minY
lazy val nextPos = pos.shift(0, height)
private def minY = children match {
case Nil => pos.y
case _ => (children map (_.pos.y)) reduceLeft (_ min _) min pos.y
}
private def maxY:Int = children match {
case Nil => pos.y + elemHeight
case _ => ((children map (_.maxY)) reduceLeft (_ max _)) max (pos.y + elemHeight)
}
}
GraphicElement define un nodo gráfico como contenedor de objetos
Line,
TextLine, y nodos hijos del mismo tipo. El resultado del proceso será un árbol de nodos de éste único tipo. Para calcular en qué posición vertical se ubica cada elemento, es necesario establecer claramente cuánto espacio vertical ocupa cada uno. Al instanciar un
GraphicElement, en
elemHeight indicamos la altura "neta" del elemento, es decir, cuánto ocupa en vertical sin tomar en cuenta los nodos hijos. Podría ser cero en el caso de un simple contenedor de nodos. Lo que no indicamos nosotros es la altura "bruta", que incluye la de los hijos. Esa la calcula el campo
height. Con el método
nextPos vemos que cualquier elemento puede determinar la posición "siguiente" que se puede usar como origen del elemento que le sigue, cuando hay varios al mismo nivel. Y lo hace en términos de la posición propia, desplazada en vertical la altura propia.
Acá vemos una versión recortada del pre-generador para gráficos. El método
generate retorna el
GraphicElement raíz del árbol.
class GraphicGenerator(totalWidth: Int)
{
// ... codigo omitido
private def layoutText(s:String, p:Pos, w:Int,
align:Alignment):List[TextLine] = // ...etc
private def makeChildren(nodes:List[Node], prevElem:GraphicElement,
w:Int):List[GraphicElement] = // ...etc
def generate(n:Node):GraphicElement = generate(n, Pos(0,0), totalWidth)
private def generate(n:Node, p:Pos, w:Int): GraphicElement = n match
{
case s:Stmt =>
val textLines = layoutText(s.text, p.shift(5, STMT_HEIGHT - 5), w, AlignLeft())
val height = (STMT_HEIGHT - TEXT_HEIGHT) + (TEXT_HEIGHT * textLines.size)
new GraphicElement(p, w, height, textLines, Nil, Nil)
case f:Loop =>
val blockWidth = w - STMT_HEIGHT
val textLines = layoutText(f.text, p.shift(5, STMT_HEIGHT - 5), w, AlignLeft())
val height = (STMT_HEIGHT - TEXT_HEIGHT) + (TEXT_HEIGHT * textLines.size)
val blockPos = p.shift(STMT_HEIGHT, height)
val children = makeChildren(f.body, GraphicElement.nullObject(blockPos), blockWidth)
val childrenHeight = GraphicElement.sumHeights(children)
val blockLines = List(Line(p.shift(0,childrenHeight+height), p.shift(w, childrenHeight+height)),
Line(p, p.shift(w,0)),
Line(blockPos, blockPos.shift(blockWidth,0)),
Line(blockPos, blockPos.shift(0,GraphicElement.sumHeights(children))))
new GraphicElement(p, w, height, textLines, blockLines, children)
// ... y el resto de los nodos del AST
}
}
Como ejemplo vemos la resolución de los nodos
Stmt (statement) y
Loop. No importan mucho los detalles, pero señalaremos un par de cosas. Usamos el método
layoutText cada vez que tenemos que generar texto; no podemos directamente instanciar un
TextLine a partir de un
String porque puede ocurrir que no nos dé el ancho disponible y haya que wrapear ese
String. El método resuelve el wrapping y devuelve una lista de
TextLine.
El método
makeChildren procesa una lista de
Node, invocando generate por cada uno, y determinando la posición de cada uno con
nextPos del elemento anterior. Le pasamos como argumento un
GraphicElement.nullObject, que es un
GraphicElement vacío que sirve sólo para definir la posición inicial de esa secuencia de nodos.
Una vez que nos sacamos de encima todo el trabajo pesado, definamos un marco para las implementaciones gráficas. Estas ya no necesitan conocer
el modelo del AST (
Node y sus subtipos:
Stmt,
Loop, etc.) porque sólo trabajarán en términos de objetos
GraphicElement.
abstract class GraphicBasedGenerator[T](width:Int) {
def generate(n:Node):T = {
val s = new GraphicGenerator(width).generate(n)
generate(s)
}
def generate(ge:GraphicElement):T
}
Esta clase ya resuelve el uso del graficador abstracto que a partir de un
Node raíz obtiene un
GraphicElement raíz. Queda por definir la generación de un
T (tipo que depende del renderizado a usar) a partir de un
GraphicElement. Entonces, implementé un graficador para Dojo Gfx como subclase de
GraphicBasedGenerator, que es bastante sencillo y no incluyo en el post para no alargarlo más.
Entradas
