[Papo-hackers] neb y layout

[John R Lenton]

Hola gentes.

Estuve pensando sobre neb (para los que no estén al tanto, neb es un
preprocesador que hemos creado para poder componentizar las pantallas
más allá de lo que nos permite gnue), y sobre la posibilidad de
automatizar el layout, es decir, hacer que neb u otro filtro tradujera
ordenes de alto nivel, por ejemplo contenedores (al estilo gtk, por
ejemplo) en el (incómodo) sistema de layout de gnue. Federico era de
la idea de que lo mejor era hacerlo dentro de neb, y creo que iba a
mirar esa ruta.

Sin embargo, estuve pensando que en realidad neb no sabe lo
suficiente aún como para hacer eso, y que si se lo agregamos a neb
sería *después* de que ya generó la pantalla, con lo cual no ganamos
nada. Esto depende de la implementación de neb, pero en este momento
es así: neb levanta el árbol de parsado del archivo (o subarchivo)
xml, pero no opera sobre el árbol a la hora de producir el contenido
sino que lo hace 'por fuera'. En un ejemplo queda más claro: Si el
archivo de entrada contiene

    <neb:Block> foreach (1,2,3) { </neb:Block>
    <label text="neb:$_" x="1" y="neb:$_"/>
    <neb:Block>}</neb:Block>

este fragmento se levanta en un árbol de parsado que contiene,
ilustrativamente,

    |- neb::Block
    |   `- neb::Stuff ("foreach (1,2,3) {")
    |- neb::Stuff ("<label ... />")
    `- neb::Block
        `- neb::Stuff ("}")

y esto se traduce en

    <label text="1" x="1" y="1"/>
    <label text="2" x="1" y="2"/>
    <label text="3" x="1" y="3"/>

que podría pensarse como

    |- neb::Stuff ('<label test="1"... />')
    |- neb::Stuff ('<label text="2"... />')
    `- neb::Stuff ('<label text="3"... />')

pero en ningún momento se forma un árbol que contenga estos tres
elementos. La razón es que no hace falta, es una complicación
adicional, y la administración dinámica de un árbol de parsado es
bastante compleja, y no algo que quisiera que neb v1 tuviera (hasta
tanto no sepamos los errores que contiene). Si tuviese esta
administración dinámica del árbol de parsado entonces sería "sencillo"
hacer que se diera cuenta de dónde y cómo acomodar los elementos
dentro de contenedores. Sin embargo, hasta este momento no hay nada en
neb que lo haga gnue-específico...

Sin embargo, si separamos esta funcionalidad en un paso adicional de
procesado posterior a neb, un postprocesador del preprocesador si se
quiere, entonces neb mantiene su simpleza (no solamente por no tener
esa funcionalidad sino además por no tener la funcionalidad adicional
para la cual hace falta aquella) y su imparcialidad (en cuanto a que
no contiene nada gnue-específico), con lo cual creo que es una
herramienta de uso más general. El trabajo adicional de reparsar el
archivo xml es muy simple, dado XML::Parser y neb::Parser; el tiempo
adicional no es significativo dado que no es tiempo de ejecución ni
nada parecido.

Ustedes y yo sabemos que hacer una cosa y hacerla bien es la forma de
hacer las cosas. ¿Por qué es que siempre nos tienta hacerlas todas
juntas en el mismo lugar?

Bueno, creo que eso es todo lo que tenía dándome vueltas en la cabeza
sobre esto. Un abrazo.

-- 
John Lenton (address@hidden) -- Random fortune:
        A educacao e para o jovem o que o cultivo e para o solo
                -- Marcelino Champagnat

pgpHwvDh_ur_Z.pgp
Description: PGP signature