piwi

I'm succeeding to speak like I'm fucking mad

Bueno, pues ya había pasado bastante tiempo que no escribía en mi blog face-smile.png . 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 tongue.png .

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=Pablo Fischer"));
$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: Pablo Fischer, que va a ser un variable que le declaremos a la acción. ¿Qué va a pasar con Pablo Fischer?. Pues va a sustituirlo por el valor del campo Pablo Fischer. 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 ion es lo que hace Orkut con las estrellitas face-plain.png .

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:

Diagrama Completo

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 tongue.png ) 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:

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 face-smile.png .

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:

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 tongue.png ) 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 face-smile.png .

Pasando a otras cosas...

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

Bueno... pos eso es todo, fue poquito, parece... tongue.png

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

Piwi, Happy Widgets for Happy People

Ú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?.

Link dump

| Archives | Feed |

Categories