lunes, 13 de octubre de 2014

Scripting GX .Net + Jint (JavaScript Server-Side)

Llevo un rato trabajando con el generador C# y en un determinado proyecto tuve que incorporar un mecanismo de scripting JavaScript server-side, que terminé implementando en base a Jint.
En este tipo de cosas se puede llegar a niveles de complejidad altos, según lo creativos que estemos, pero acá les dejo un par de ejemplos sencillos. A ver si algunos se animan y hacen sus primeras pruebas en este tema.

Caso 1

Se trata de cómo pasar variables sencillas al engine y ejecutar un JavaScript que use esas variables, en este caso sólo con una instrucción return:
 &idVarchar = "miVariable" //id de la variable en el script
 &miVarchar = "Hola Mundo!" //valor de la variable
 &jsVarchar = "return miVariable;" //script del usuario

Acá viene el código C#:
 csharp try {  
     csharp Jint.JintEngine engine = new Jint.JintEngine();  
     csharp engine.SetParameter([!&idVarchar!], [!&miVarchar!]);  
     csharp var result = engine.Run([!&jsVarchar!]);  
     csharp [!&returnVarchar!] = result.ToString();}  
 csharp catch (Jint.JintException e){  
     csharp [!&returnVarchar!] = e.Message;}  
 csharp catch (Exception e ){  
     csharp [!&returnVarchar!] = e.ToString();}  
- Instanciamos el engine
- Pasamos nuestra variable al engine
- Le damos run con el script de una línea
- Y el retorno lo pasamos a una variable varchar (debería traer "Hola Mundo!")
- Si hubiera errores, los atrapamos y retornamos la descripción.

Caso 2

En este ejemplo tomaremos una variable basada en un SDT y la pasamos al engine como un string Json.
 &xidVarchar = "Persona" //id del objeto a crear en el script
 &idVarchar = "jintJson" + &xidVarchar //id del string Json en el script
 &sdtPersona.Nombre = "John Doe Jr." //datos en la variable &sdtPersona
 &sdtPersona.Edad = 35
 &miVarchar = &sdtPersona.ToJson()  //pasamos la variable sdt a un string json
 //iniciamos el script con un eval que transforma el Json en un objeto JavaScript
 &jsVarchar = "var " + &xidVarchar + " = eval('(' + " + &idVarchar + " + ')');" + newline()
 + "//inicio del script del usuario" + newline()
 + "return Persona.Nombre;" + newline()
El código C# es igual al del Caso 1:
- Instanciamos el engine
- Pasamos nuestra variable string Json al engine
- Le damos run con el script que inicia transformando el Json en el objeto Persona
- Y retornamos Persona.Nombre a una variable varchar (debería traer "John Doe Jr.")
- Si hubiera errores, los atrapamos y retornamos la descripción.

Bonus Track

Si se requiere conocer el tipo del valor de retorno, podemos hacer algo apoyándonos en GetType():
 csharp Type typeX = result.GetType();
 csharp [!&typeVarchar!] = typeX.Name;
 do case
     case &typeVarchar = "Double"
         csharp Double returnDbl = (Double)result;
         csharp [!&returnVarchar!] = returnDbl.ToString("F4",System.Globalization.CultureInfo.InvariantCulture);
     case &typeVarchar = "DateTime"
         csharp [!&returnDateTime!] = (DateTime)result;
         &returnVarchar = &returnDtt.ToFormattedString()
     otherwise
         csharp [!&returnVarchar!] = result.ToString();
 endcase

viernes, 10 de octubre de 2014

Pendientes del Live Editing

Estuve la semana pasada en Montevideo con motivo del evento GeneXus 2014 y como siempre quedan muchas cosas dando vueltas por ahí, ideas nuevas, otras no tanto, novedades interesantes y la sensación de que iniciamos nuevamente un ciclo junto a GX.

Ahora les voy a comentar de una de las sorpresas del GX24: el “Live Editing”. Una funcionalidad que podremos ver en la próxima versión de GeneXus, ¿o tal vez antes, en alguna actualización de la Evolution 3?.

De qué se trata el “Live Editing”? Bueno, ni más ni menos que de permitirnos hacer cambios en un objeto y reflejarlos de inmediato en una instancia en ejecución, sin necesidad de build y deploy.


Por ejemplo, puedo estar modificando definiciones en el editor de temas y ver el resultado al instante en los formularios de una aplicación que está corriendo en Tomcat, sin necesidad de hacer build, en algo que parece ser “simplemente” el reemplazo de archivos CSS en el directorio de la aplicación.

Pero es bastante más que eso.

La presentación que vimos iniciaba con algo parecido, pero luego iba a más, derechamente modificando el layout en un panel de una aplicación corriendo en IOS en la que se apreciaba de inmediato el cambio de posición de los elementos. Y para coronar todo, más allá de colores y layouts, pudimos ver un live-editing de un evento de usuario donde el presentador cambió el código y tras un pestañeo la aplicación cambió su comportamiento de mostrar un detalle a mostrar un mensaje.
Luego en la keynote final pudimos ver un ejemplo más impactante: en vez de levantar un popup, ahora pedía tomar una foto y la tuiteaba!


Está muy buena la posibilidad de hacer, o afinar, el diseño con este mecanismo, aunque en lo personal no quiero tener nada que ver con el diseño. Yo preferiría que el diseñador me entregara unos templates html que yo incorporara a la KB y nada más.
También está muy bueno que podamos verificar y corregir el comportamiento de algunos programas sin tener que pasar por el build. En lo personal esto último me importa más.

Pero, bueno, independiente de las preferencias de cada uno, el "Live Editing" contribuirá de buena forma en hacernos más efectivos y productivos con GX.

Por otra parte, sería interesante conocer un poco de en qué se basa la implementación del “Live Editing” en los diferentes generadores. Creo que en general debe tratarse de algunas técnicas de “hot swap” de clases , que consiste en reemplazar las clases cargadas en la máquina virtual (hablando de Java) sin necesidad de reiniciar algo.