[LUG.ro] Fwd: Para desarrollar aplicaciones bajo GNU/Linux: un cimarron que no es amargo
Sebastián D. Criado
lugro@lugro.org.ar
Sat, 14 Feb 2004 14:18:43 -0300
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
- ---------- Mensaje reenviado ----------
Subject: Para desarrollar aplicaciones bajo GNU/Linux: un cimarron que no es
amargo
Date: Viernes 13 Febrero 2004 18:42
From: Federico Heinz <fheinz@vialibre.org.ar>
Amigos,
les quiero contar de un sub-proyecto de PAPO que Vía Libre está llevando
a cabo, y que creo que es de interés para todos los que quieren
desarrollar aplicaciones administrativas bajo GNU/Linux. Para los
impacientes: se llama "cimarrón", y lo pueden bajar de la página de PAPO
(http://papo.vialibre.org.ar), por cvs anónimo (para tener una versión
más actualizada y con más funcionalidad --- esto está avanzando muy
rápido) con el comando:
cvs -z3 -d anoncvs@savannah.nongnu.org:/cvsroot/papo co cimarron
(para que esto funcione, tienen que tener ssh versión 2 instalado, y en
algunas distros, van a tener que exportar la variable de entorno CVS_RSH
con el valor 'ssh', es decir "export CVS_RSH=ssh")
Mientras lo bajan, les cuento la historia: cuando empezamos PAPO,
salimos a buscar un ambiente en el cual basar el desarrollo. Teníamos
una serie de requerimientos, el más fuerte era que tenía que ser
multi-todo: multi-capas, multi-UI (gráfico, caracter, web),
multi-plataforma, multi-base de datos... Dimos muchas vueltas, nos dio
la impresión de que GNU Enterprise cumplía con nuestros requisitos, y
comenzamos el desarrollo basándonos en ese proyecto.
Con el paso del tiempo, lamentablemente, comenzamos a descubrir
problemas serios con nuestra elección: para ser multi-todo, GNUe había
sacrificado una serie de cosas que consideramos importantes, pero por
sobre todas las cosas, tenía un problema de diseño que nos complicó
mucho la vida: es un solo aparato monolítico que abarca desde la UI
hasta la conexión SQL: tiene su lenguaje de descripción de pantallas (en
XML), su application server (que sólo está diseñado, y falta para la
implementación), su interfaz a la base de datos... y no se puede
mezclar. Si vas a hacer GNUe, tenés que agarrar todo, no podés usar sólo
un pedazo, o reemplazar un pedazo por algo que te guste más.
Al final, la versión 0.2 de PAPO está ahí, funciona en varios lados,
pero no estamos conformes. Por un lado, la presentación del sistema es
muy espartana, pero más que nada, lo que hay debajo de capot no nos
satisface: la lógica de negocios está muy atada al GUI, la falta del
servidor de aplicaciones para "sostener" nos forzó a encontrar
soluciones bastante ad-hoc y muy procedurales. Como consecuencia,
decidimos que obviamente GNUe no es lo adecuado por nuestro proyecto, y
buscamos con qué reemplazarlo.
Encontramos algunas cosas muy piolas, que antes no habíamos visto (o aún
no estaban). Decidimos seguir con Python, como lenguaje, por
considerarlo de los menos "atemorizadores" para novatos, y encontramos
un sistema de persistencia objeto/relacional para Python (stand-alone o
bajo Zope) inspirado en el Enterprise Objects Framework de Apple. Se
llama Modeling (http://modeling.sf.net/), y se los recomiendo tres
veces. Es un muy buen trabajo de Sébastien Bigaret que hace un muy buen
balance entre magia y simplicidad (es decir: no invierte enormes
cantidades de magia en resolver cosas que se pueden arreglar fácilmente
con un poquito de esfuerzo de parte del programador). Sébastien además
es un líder de proyecto de esos de los que a uno le gustaría que hubiera
más: considerado, atento, capaz, muy buen comunicador.
Para application server encontramos tantos distintos, que decidimos
postergar la decisión para más adelante, sabiendo que al menos siempre
tenemos la posibilidad de usar a Zope como opción de fallback.
Nos queda el tema del UI, y allí no encontramos nada que nos
satisficiera. No queríamos pegarnos a GTK o a QT, y ni siquiera a una
interfaz gráfica. Por lo demás, la mayoría de los widget sets que andan
dando vueltas por ahí están diseñados para manejar una interacción muy
compleja con el usuario: la idea es que con ellos uno pueda escribir
*cualquier* aplicación. Pero los programas administrativos por lo
general tienen un modelo de interacción muy simple, y la funcionalidad
"excesiva" de los widgets lleva a que el programa deba ser más complejo
que lo que hace falta. En realidad, a algunos nos gustó Entity, pero ese
proyecto ha muerto para renacer como Oblingua en algún momento del
futuro, pero no sabemos cuándo.
Ahí nace, entonces, Cimarrón. Se trata de un juego de widgets abstracto,
que define cosas como campos de entrada de texto, de fechas, checkboxes,
etc, sin decir *nada* acerca de su apariencia en pantalla, y un modelo
de interacción simplificado. Una aplicación desarrollada usando Cimarrón
crea instancias de esos widgets, los que a su vez crean instancias de
los widgets concretos con los que interactúa el usuario. El chiste está
en que los widgets concretos pueden estar implementados en cualquier
cosa. Actualmente los tenemos implementados en GTK y GTK2, como
ejemplos, y se pueden hacer las clases correspondientes para que la
aplicación funcione usando QT (debería ser fácil), o curses (más
laburo), o...
Todavía no tenemos un formato XML para describirlo estáticamente, ni un
constructor de GUI gráfico, sino que hay que construir las instancias
usando código, pero ninguna de estas cosas debería ser complicada.
A esta altura ya debe haber bajado (no es muy grande). No hay
documentación formal aún, pero estamos trabajando en mejorar la
consistencia de los comentarios y los docstrings en el código, y hay
ejemplos de cómo hacerlo andar (algunos pueden requerir que instalen
Modeling y PostgreSQL). Los invito a que lo prueben, le peguen, lo
critiquen... ¡y sobre todo contribuyan! :-)
Abrazos,
Fede
PS: ¿Por qué "cimarrón"? Bueno, lo que pasa es que está pensado
siguiendo el pattern "Model-View-Controller", también conocido como
"MVC". Se nos ocurrió que un nombre lindo para algo que implementa MVC
podía ser "MaVeriCk"... pero lamentablemente no fuimos los primeros en
pensarlo: hay como cinco proyectos que se llaman así, y no quisimos
repetir el fiasco de Firebird, pero "maverick" se traduce al castellano
como "cimarrón", y buscándolo en el diccionario nos encontramos con que
tiene varias acepciones:
cimarrón, -rrona
1 adj. [animal doméstico] Que huye al campo y se hace montaraz.
-
2 adj.-s. Amér. Esclavo que huía buscando la libertad. -
3 adj. [animal] Salvaje, por oposición al domesticado; [planta]
silvestre, por oposición a la cultivada.
4 R. de la Plata. [mate] Sin azúcar.
5 Chile. Holgazán, perezoso. -
6 adj.-s. MAR. Marinero indolente. -
7 m. Colomb. Aromo, árbol leguminoso.
De todas ellas, la única que no nos pareció pertinente fue "árbol
leguminoso", así que lo adoptamos.
- --
GnuPG Public Key: gpg --keyserver wwwkeys.eu.pgp.net --recv-key BD02C6E0
Key Fingerprint: 04F4 08C5 14B7 2C3D DB21 ACF8 6CF5 0B0C BD02 C6E0
- -------------------------------------------------------
- --
- --
Sebastián D. Criado - scriado@ciudad.com.ar
L.U.G.R.o - http://www.lugro.org.ar
GNU/Linux Registered User # 146768
- -------------------------------------------------------------------
"Si el Universo fuera un programa estaría hecho en C, y correría sobre
un sistema UNIX"
Anónimo.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFALlhz8hmHQ8ZCg0IRAhBBAJ0UYA8lWoizeGNJIyoYxG88yUM3PQCgtFHC
5rjD93H5Fvy3gQap7lXpel8=
=H+Hz
-----END PGP SIGNATURE-----