Pablo Fischer

Bueno, pues ya había pasado bastante tiempo que no escribía en mi blog . Y es que últimamente he estado medio ocupado tirando código en piwi. ¿Pero que ha pasado en piwi?, ¿Cómo va el proceso de Piwi?… pues de eso voy a hablar .

Lo que va…

Actualmente Piwi cuenta con un gran número de binary widgets (los que pueden tener eventos) y de container widgets (los que pueden tener a otros widgets). De los binary widgets pues ya contamos con entries, buttons, combos, etc. De los containers pues tenemos boxes, un menubar, fieldsets, etc.

Hace poco encontré una página en la que vienen muchos widgets en javascript muy sencillos de utilizar. Uno que me llegó a interesar fue el Sortable Table el cual te permite ordenar una tabla en XHTML (como Piwi maneja todos los widgets) sin tener que andar recargando la página. Entonces ahora si se quiere crear un DataGrid va a ser muy fácil:

$grid = new DataGrid ($array, "Valores");
$grid->AddColumn (new Column ("Hola", "name"));
$grid->AddColumn (new Column ("Nickname", "nick", false));
$grid->AddColumn (new ActionColumn ("Mover", "?accion=mover&nombre={name}"));
$grid->Show ();

La interpretación es sencilla: se crea un datagrid con un array y su título (opcional) que va a ser representado por un ‘caption’, cabe notar que el formato del arreglo ($array) debe ser similar al que regresa la función mysql_fetch_array() en PHP. La siguiente linea va a agregar una columna que va a tener cómo título: ‘Hola’ y los datos que va a tener la columna serán aquellos que se encuentren en el field ‘name’ del array, por ejemplo:

$array = array ();
 
$array[0]["name"] = "Pablo Fischer";
$array[0]["nick"] = "pabl0";
 
....

La siguiente columna va a tener el título de ‘Nickname’ y va a tener el campo de ‘nick’. ¿Pero qué es ese false?. Pues le indica que ese campo no puede ser ordenado (por default va a dar la opción de que también se pueda ordenar esa columna).

La siguiente instrucción del DataGrid es crear las acciones (opcionales) que tendrá. Las acciones son aquellas de: Agregar, Editar, etc. Entonces le vamos a agregar una acción que tendrá por nombre: ‘Mover’ y su acción (el action). La acción tiene un detallito: {name}, que va a ser un variable que le declaremos a la acción. ¿Qué va a pasar con {name}?. Pues va a sustituirlo por el valor del campo {name}. Quedando algo asi:

<a href="?accion=mover&nombre=Pablo Fischer">Mover</a>

Lo que viene…

Últimamente he estado leyendo todo lo relacionado con XmlHttpRequest. Que básicamente es el enviar un request (POST o GET, principalmente) en el ‘fondo’ de la aplicación. Supongamos lo siguiente: Tenemos un formulario para logear al usuario, campo de usuario y campo de password, entonces cuando el usuario le de click en ‘Log in’ se haga el request en background (sin recargar la página ni mandarlo a otro lado) a un ValidateUser.php en donde se valida el usuario y regresa un XML que interpretaremos con la ayuda de XmlHttpRequest y si el usuario es invalido pues se mostraría un mensaje de error (en un div, por ejemplo) o mandando al usuario a otra página. Vaya.. como dice [friend]ion[/friend] es lo que hace Orkut con las estrellitas .

Bien, pues he estado platicando con Antonio Ognio sobre usar XmlHttpRequest, aunque ya venía leyendo desde hace tiempo sobre su uso.. pues Antonio me convenció de usarlo en algunas cosas. ¿Pero cómo cuales?. Bueno pues voy a usarlo en el widget de Form para validar los campos (tipos y si el campo no debe estar vacío). La idea es parecida a:

Básicamente es: El usuario cuando le de submit a su formulario los campos se van a enviar por XmlHttpRequest a piwi/Tools/ValidateForm en donde se analiza cada campo: si es requerido y si necesita algún tipo de formato/dato en especial (enteros, precios, fechas, etc), de acuerdo a la respuesta va a regresar un XML con la respuesta de si los campos son correctos o no, si no lo son va a agregar los campos que tienen los errores dando la descripción del error. Cuando la página ya obtiene la respuseta del XmlHttpRequest, el Javascript va a leer el XML y mostrar los erores (si hay) en algún lado, así como marcar (con un tache o algo) los campos que no son validos.

Otra de las cosas que van a venir (pero no en el primer release, ni el segundo, ni el tercero ) es mezclar XSLT y PHP. Ya saben, la idea de piwi es hacer las cosas muy similares a como se hacen en ASP.NET, así que platicando con Antonio llegamos a la idea de programar los widgets en XSLT, es decir, en lugar de tener:

$button = new Button ("boton", "Boton");
$button->SetSubmit ();
$button->SetStock (STOCK_CANCEL);

Tener:

<piwi:Button name="boton" value="boton" stock="stock_cancel" />

Con eso piwi dejaría de ser un vil proyectito en PHP que genera widgets a una opción CASI parecida (ya que carecemos de un bonito IDE como VS.NET). El tener XSLT va a ser algo divertido pero muy tardado, he visto algunos ejemplos de pasar XSLT a algún código y son muchas reglas.. y porque no.. también una opción extra a php-gtk .

Y bueno, ya que estamos por las tierras de XML, posiblemente en el primer release tengamos un piwiXML que va a permitir generar widgets de un archivo XML, para esto queremos tener nuestro DTD para validar los widgets. La idea es básicamente:

$piwi = new Piwi ("archivo.xml");
$piwi->Show ();

Que archivo.xml podría tener:

<button name="boton">
 <value>valor</value>
 <stock>cancel</stock>
</button>

Y no.. no pensamos reinventar el hilo negro de XUL o XAML (Avalon), de hecho la idea es que un widget o un conjunto (container) se puedan crear en glade y con un sencillo script en Perl se pueda convertir de un .glade a un piwiXML, o igual de un xul, o viceversa, pero por nada pretendemos sustituir a XUL (ya que nos hemos estado basando tanto en XUL como en Gtk# para los widgets).

Algunas dificultades…

Cuando estaba trabajando en el Menubar me encontré con dos problemas: usar un Javascript todo cerdo o crearlo con CSS (hojas de estilo). El camino que tomé fue el de CSS, sin embargo me encontré con que muchos navegadores (que sorpresa ) no soportan muchas cosas de CSS (que son permitidas, según w3c), como por ejemplo usar el atributo hover en listas. Konqueror, Opera (aunque ya tiene el parche) e IExplorer no lo soportan.. así que ni modo.. o usar estándares o no.. ni modo, lo siento por los navegadores que no tengan un buen soporte de estándares, para eso tenemos al Gecko .

Pasando a otras cosas…

Pues ya felicité a [friend]ion[/friend] por su cumpleaños . ion, por el 20 de noviembre llega tu regalo. Kad, espero que no te hagas wey y me mandes la mitad del regalo! .

Bueno… pos eso es todo, fue poquito, parece…

De mi proceso como NM, pues por fin me respondió Joerg Jasper (mi Application Manager).. pff.. parece que el proceso de DD va a ser largo, aparte que tengo al AM más exigente :-S. Crei que ya ibamos a pasar a la etapa de T&S (Task and Skills), pero no.. falta revisar toda ala parte de filosofía de SL, OS, etc.. pff.. va pa’ largo.

The Vines - Autumn Shade

Leyendo el log del canal de #jaws en el IRC encontré un bello fragmento:

<kad_> usa apt
<kad_> jeje

Últimamente el equipo de desarrollo (el activo) de Jaws (ion, imsck8, kad y yo) estabamos creando muchos widgets para Jaws. Sin embargo llegué a encontrar algunas cosas ‘fastidiosas’ en las herramientas que hemos creado para Jaws. Un ejemplo.. es eso: los widgets. Los JawsWidgets (los actuales) hacen maravillas, a un botón le agregan miles de cosas y te regresan widgets 100% xhtml…. pero… son inutiles si las quieres usar en otra aplicación, en mi caso he estado creando muchas herramientas de administración para el Tec usando gran parte de Jaws MVC (Model View Controller)y resulta fastidioso andar renombrando los archivos, cambiando el nombre de las clases…. etc..etc.. así que decidimos separar las cosas por proyectos: Un proyecto por separado que te permita hacer widgets con la misma facilidad que se hace en ASP.NET (o tratar de llegarle mas que nada).

Pues hemos creado un nuevo proyecto: piwi – Happy Widgets for Happy people.

La idea de piwi es como ya la mencionamos, crear widgets de manera fácil, ‘customizables’ y en un estilo de programar en C# y Gtk. La separación de los Widgets es muy parecida a Gtk, incluso me basé en Gtk para armar el diagrama de distribución de los Widgets, así como de los directorios. Hay tres tipos de Widgets:

• Bin: Widgets que pueden tener funciones de JavaScript y tienen interacción con el usuario (es decir, pueden ser ‘clickeados’).
• Containers: Los famosos ‘contenedores’. Van a ser aquellos widgets que pueden contener a otros: Cajas (Box: Hbox, Vbox), TreeView’s, ViewPort’s, Toolbars.
• Misc: Todos aquellos que practicamente ni al caso: Labels, Datagrids (no es ni contenedor ni bin), Forms (ni uno, ni otro), etc.

El tipo de Widgets de Bin pueden tener acciones, ¿Qué quiere decir?. Que se les pueden ‘pegar’ acciones de Javascript de la manera más fácil, veamos un ejemplo:

$button = new Button ("boton", "Boton");
$button->SetSubmit ();
$button->SetStock (STOCK_CANCEL);
$button->AddEvent (new JSEvent (ON_CLICK, "javascript:alert('Hola Mundo');"));
$button->Show ();

Vamos, algo muy fácil: se crea un objeto, se le da la propiedad de ’submit’, sino se le da nignuna propiedad: reset o submit pues es un simple button. Luego se le declara un STOCK (piwi cuenta con 52 stocks), y la parte intersante viene: Eventos:

Se le va a agregar un Evento JS, es decir: un evento JavaScript, el cual es muy fácil de entenderle: va a ser ejecutado cuando se le de click: ON_CLICK y va a ejecutar esa acción. Cada widget (y los oficiales de piwi) van a contar con validadores de eventos, es decir: no se va a agregar un evento que no es soportado (de acuerdo a la spec de XHTML), como por ejemplo agregar un ON_CHANGE regresarí a un error ya que los botones no pueden tener ese atributo.

Otra ventaja de los Widgets es que pueden ser: multieventos de un mismo tipo. Es decir, yo puedo agregar el número de eventos que quiera a mi widget y todos pueden ser: ON_CLICK. Las pruebas que he hecho con 10 eventos de tipo ON_CLICK me regresan un botón 100% valido de XHTML.

Y así como creamos el botón pues va a ser igual para cualquier widget, y sea Entry, Combo (contamos con 3 tipos: Normal, con Imágenes y de Grupos), TextArea’s, etc.

Por ejemplo:

$entry = new Entry ("cajita", "Una cosa");
$entry->SetAutoStyle ();
$entry->AddEvent (new JSEvent (ON_CHANGE, "javascript:alert(this.value)"));
$entry->AddEvent (new JSEvent (ON_CHANGE, "javascript:alert(calcMD5(this.value));", 
							   "http://jaws.com.mx/templates/controlpanel/md5.js"));
$entry->Show ();

Esto es más que obvio (aunque a muchas personas no les guste la: obviedad). Creamos un Entry, le agregamos un AutoStyle (que va a ser: piwi).. un dato curioso que se me olvidó: Los widgets son 100% customizables a CSS y el CSS que regresan es iguall 100% CSS. Y se le van a agregar dos eventos de tipo ON_CHANGE: El primero va a mostrar una alerta del contenido del valor y el siguiente va a hacer una alerta con el valor MD5 ejecutando la función calcMD5 que se encuentra en http://jaws.com.mx/templates/controlpanel/md5.js, ¿Qué nos regresa?.

<script type="text/javascript" language="JavaScript" src="http://jaws.com.mx/templates/controlpanel/md5.js"></script>
 
<input type="text" name="cajita" id="cajita_20" value="Una cosa" class="piwi" onchange="javascript:alert(this.value); alert(calcMD5(this.value));" />
<select name="opciones" id="opciones_13">

Piwi va a hacer la magia de acoplar los multieventos, agregar los archivos externos de JavaScript en un lugar que no tenga conflictos con el XHTML.

Bien, otra de las ideas que tenemos en piwi no es el tratar de reinvertar el hilo negro. Actualmente nos estamos basando en las propiedades que tienen objetos de Gtk, así como en XUL. Es decir, que los usuarios puedan armar sus interfaces en XML y cargarlas (tener nuestros parsers) y arrogar 100% Xhtml. Hay dos lugares donde me ando basando: XAML (un XUL para Longhorn y Avalong, los drafts son excelentes) y XUL (diseño de GUI’s, pero opensource y desarrollado por la gente de Mozilla). Aunque vamos a tener nuestro propio archivos, vamos a poder convertir nuestro Widget (de objetos a XML) a XUL o Glade y viceversa. Posiblemente nos lleguemos a basar más en XUL, teniendo algo como:

<menubar>
<menu name="File">
    <menu name="New">
        <menuitem name="Navigator" cmd="commandid:newnavigator" />
        <menuitem name="Message" cmd="commandid:newmessage" />
        <menuitem name="Blank Page" cmd="commandid:newblankpage" />
        <separator/>
        <menuitem name="Blank Page From Template..." cmd="commandid:blankpagefromtemplate" />
    </menu>
....

Que básicamente sirve para crear un MenuBar con sus menuitems y mil cosas. Lo más cansado va a ser el desarrollar el DTD y no por que vaya a ser complicado, sino porque es muy cansado… son muchas reglas a definir para tener un bonito DTD.

¿Cuál es la meta de Piwi?. El ofrecer una herramienta a los programadores de PHP para desarrollar interfaces 100% estándares y los programadores se olviden del tan cansado JavaScript y HTML al mismo tiempo: Tener la menta en PHP y hacer que el progamador traté de olvidarse de XHTML y CSS (bueno, a menos qu equiera agregarle un bonito CSS ).

Pensamos usar la herramienta de Glade para desarrollar interfaces en un futuro muy cercano. Por ejemplo, tener un: phoo.addalbum.xml que regresaría una interfaz para agregar un Album al gadget Phoo. Desarrollarla en Glade, pasarla al XML de Piwi (algun script con Perl nos ayudaría bastante) y guardarla y simplemente hacer:

$piwi = new XML2Widget ("phoo.addalbum.xml");
$piwi->Get ();

.

Nuestro triste México

Yo a diferencia que muchos Mexicanos me siento triste del México que vivimos en la política.. ahora el PRD toma la Cámara y hace sus cosas… los del PRD ahora dicen que el negociarlos por hacer su chiste tan estúpido es otro complot.. complots por aquí y complots por allá.

Muchos mexicanos ‘izquierditas’ o amantes de ‘La Jornada’ (que no es más que un blog del PRD) aseguran que eso es un complot.. el decirle a los estados: Cada quiens e paga lo suyo. Vaya, esos planes llevan desde el 94-95…. y ahora es ¿qué?.. un complot. La estúpida del PRD: Dolores Padierna se sube a la silla del Presidente de la Cámara a hacerse la chistosa… bah… yo no entiendo porque la gente le interesa tanto ese pinche partido que por cada propuesta que sacan dicen que no y que no y que no…

Muchos como son fanaticos de Obrador igual.. dicen que el gobierno Federal debe seguir pagando el dinero al DF por la educación y AMLO no quiere.. pues si, como el no hace nada y ese presupuesto lo hace para puentes estúpidos y otras cosas pues no le conviene porque dejaría a la mitad todas sus metas: Puentes.

En fin… hace rato pensaba: Ya que se chinguen a alguien del PRD o al partido. No quiero imaginarme en la que se metieron con sentarse y ocupar la Cámara y no solo insultar a los del PAN.. sino a la mafia de mafias: PRI… en fin.. mis deseos para que pierdan en el 2006.. y ya.. sea cual sea la manera…. si eso hacen sin tener todo el poder, teniendo el poder no me imagino… Pero en fin.. uno a fregarse la espalda para salir adelante, buscando apoyo en prd’istas no se llega a nada..

Ando escribiendo un artículo sobre la Cámara y las estupideces del PRD al estilo de: Elecciones al 2006, pienso terminarlo el Martes y publicarlo, va a tener una gran fuente de datos .

Voy a tratar de dejar de escribir estúpideces sobre México, ya me hicieron el comentario: Parece más de lo mismo .

El comentario solo fue de coraje y resentimientos con el único objetivo de insultar al PRD

En un breve descanso (estaba estudiando) me pasaron una liga para saber que personaje de videojuego se identificaba con tu personalidad y puss… decidí probarle.

Y bueno…. la maldita página le atino a casi todo (yo diría un 95%).. pfff… I’m a breakout bat!!

I am an abstract sort of creature, who dislikes any sort of restraint. If you try to pigeonhole me, I'll break the box, and come back for more. I don't have any particular ambitions, I just drift, but I am adept at keeping life going along.

La página es: What Pre-1985 Video Game Character Am I?