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.

Superheroic GeneXus (GX+AngularJS)

He estado experimentando con una idea de pattern, descubriendo algo un tanto obvio: que se trata de una gran cantidad de trabajo!!!

Pero bueno, es mi idea de pattern, ver cómo generar automáticamente una aplicación basada en un template bootstrap que compré por ahí, y estaba en eso, pensando cómo iba a hacer para emular lo de la MasterPage y el ContentPlaceHolder, y me voy dando cuenta que lo ideal era usar otro template que tiene una versión basada en ¡AngularJS de Google!.

Siempre es bueno descubrir algo nuevo e investigar de qué se trata, así que me puse a leer por aquí, por allá viendo unos videos, de paso me enteré de que hay un Kindle para android, y resultó  que AngularJS pretende ser “lo que HTML debió haber sido”, “HTML mejorado para web apps”, “Superheroic JavaScript MVW Framework”. Lo de MVW me causó gracia.

Básicamente, AngularJS se trata de un conjunto de cosas JavaScript, que permiten, por ejemplo, agregar tus propios tags a la sintaxis HTML y también hacer algo de data binding.

El data binding es la funcionalidad para hacer que un elemento que se muestra en una pantalla esté ligado a un origen de datos, de tal forma que si en los datos hay un cambio de valor, dicho cambio se refleje en la pantalla automáticamente. No es nada nuevo en realidad. Lo interesante es cómo lo implementa AngularJS con templates HTML y objetos JavaScript.

Una forma de data binding en GeneXus es, por ejemplo, cuando ponemos atributos directo en un webform, o en un grid. Nada más es necesario. Sabemos que en la pantalla vamos a ver los valores. Otra forma es cuando cargamos valores en una variable SDT relacionada a un UserControl: el desarrollador se ocupó de lo necesario para que la data se visualize como corresponda, o sea, implementó el data binding.

De vuelta a mi proyecto, estaba en eso de pensar el pattern, construyendo las primeras cosas: templates html, procedures http, business components, data providers y otros, pero nada de webpanels. “Nada de webpanels” estaba diciéndome, pensando cómo lo hago con los eventos y las variables de sesión, y de pronto me salté para otro lado y me imaginé que bueno estaría que GX hiciera el HTML y JavaScript basado en este framework de Google.
Podría ser que estamos frente a un nuevo desafío para ARTech: el reemplazo del actual marco HTML-JavaScript de GeneXus por uno basado en AngularJS.

Con todo lo interesante que me pareció esto de AngularJS y la oportunidad que, a mi modo de ver, representa para GeneXus, también se me hace que este tipo de herramientas, que empiezan a ir en dirección de abstraernos del detalle, de automatizar muchas tareas, también podrían ser vistas como “amenazas”.

Y me vino de vuelta una frase que escuché por ahí: “el mayor problema de GeneXus es que no tiene competencia”. Porque es cierto, no existen competidores directos, que se puedan distinguir con claridad, que ofrezcan la efectividad y productividad que nosotros podemos lograr con GX.
Y es un problema, porque la competencia haría mejor y más fuerte a GX.

Múltiples condiciones por atributo

A propósito de un pattern que estoy ideando, reparé nuevamente en este asunto y me animé a dejar alguna idea aquí.

Se trata del tema de todos los Where que debemos escribir cuando queremos que la consulta tenga un cierto dinamismo:

Si todo el trabajo lo va a hacer el pattern, no habría de que preocuparse mucho, sean 10 o 50 repeticiones. Pero, claro, ese código no se ve muy "elegante".


A mi me gustaría que tuviésemos una función para usar en conjunto con la cláusula When. Algo así como esto:

La variable a usar estaría basada en un SDT con la estructura necesaria para cargarla con todos los valores y operadores, y esa información se usaría para construir el "where" del query, tal como se hace hoy con las condiciones que incluyen la cláusula When.

Saludos!!!

Variables basadas en estructura local

Ando por estos días un tanto creativo, y se me ocurrió dejar este post con un deseable para el editor de variables:

Como se aprecia en la imagen, la idea es que podamos declarar variables basadas en una estructura, y colecciones para usar con las mismas.

Con algo así ganaríamos no tener que definir tantos SDTs que muchas veces sólo se usan puntualmente en uno o dos programas.

Saludos!!!

jqGrid con DataProvider y una idea de pattern

Bueno amigos, aquí estamos con todas las cosas que han estado ocurriendo, todo lo de Smart Devices y ahora la Ev3 con lo de Responsive Web, que me ha dejado atento a lo que hará la gente de DVelop, K2BTools y PXTools con sus respectivos patterns.

En particular, relacionado con lo de jquery-bootstrap-etc, he estado pensando en otra forma de enfocar la generación de la interfaz web, con un nuevo pattern, que directamente generaría HTML y no webpanels GX. Algo parecido a esto seguramente ya lo ha practicado más de alguno: tener un sitio hecho "a mano" que se enganche de alguna forma a programas generados con GX, vía Ajax, por ejemplo.

Para empezar a dar forma más concreta a la idea del pattern, me puse a trabajar en el "canonical example", basándome en una plantilla bootstrap (Ace), tratando en primera instancia de levantar la misma plantilla y enlazar un jqGrid a un DataProvider con paginado.


Así quedó:

La gran tarea aquí es descomponer el diseño original y crear una serie de procedures que retornen el contenido según se requiera.Y a partir de eso ir dando forma al pattern que luego producirá automáticamente los objetos necesarios.


Paso a contarles algunos detalles del ejemplo y en particular de cómo lo hice con el jqGrid.

El programa principal es un procedure Main con Call Protocol HTTP que devolverá todo el html. Podría entenderse como una MasterPage con un navbar, un sidebar y un "ContentPlaceHolder".

El siguiente fragmento corresponde a un procedure que genera contenido de diferentes páginas según una variable "&pageId". En particular en este caso, se incluyen los tags necesarios para la carga del jqGrid en la página "wwproducto".

Luego, en otro procedure se incluyen los scripts. Aquí vemos parte del código que dibuja el grid y el pager en los tags mencionados antes, y el enlace al programa que retorna el json.

Lo más probable es que esto finalmente quede en procedures separados, a ser generados mezclando código de usuario y código automático a partir de la información de la instancia del pattern en los objetos en que se aplique.

A continuación la definición de la estructura a usar para la consulta de datos y carga del jqGrid. En el primer nivel van los parámetros requeridos por el pager, y en la colección los datos solicitados. El pattern debiera generar estas estructuras para cada transaction que se requiera.

El siguiente es el procedure (main, call protocol http) invocado por la jqGrid. Aquí tomamos los parámetros del request, propios de jqGrid (con un poco de csharp), hacemos la llamada al dataProvider y retornamos el json.

 Y finalmente el DataProvider que hace la magia.

Claramente esto es una aproximación al tema y quedan muchos asuntos por ver y resolver. Además de las cosas que pueden cambiar en el camino. Por decir algo: el template que escogí acaban de actualizarlo y esta vez viene con una versión full Ajax.

Se pone interesante.

Scripting con GX Java

Amigos, luego de una -demasiado- larga ausencia, aquí estamos nuevamente para compartir de alguna forma en torno a GeneXus.
Hoy me animo a postear algo sobre el tema de scripting en Java.

Lo de hacer scripts para dejar las aplicaciones con cierto dinamismo, siempre me ha llamado bastante la atención. Al punto que siempre ando buscando en qué poder usar una solución de ese tipo.

Y, así y todo, estaba tranquilo por la vida hasta que -hace unos meses atrás- leí en el foro: "Hola gente, quería saber si es posible agregar algun código Javascript en un procedimiento?".
De inmediato reaccioné con lo de JScriptSrc y JSEvent , y un textblock-raw-html y no sé qué otra cosa que no tenía nada que ver con la pregunta...
Después de un rato me quedó claro que por el lado del cliente no era el tema. Que no era un javascript a ser interpretado por el browser, que tenía que ser server-side y punto!. O capaz que ni se trataba de algo web...

Después de investigar un poco descubrí que había miles de cosas respecto de scripting en el mundo Java y que el mismísimo Javascript se puede usar desde hace un buen tiempo.
No voy a entrar en detalle de las implementaciones que existen, ni de la historia del tema, ni de todos los lenguajes de script que podríamos usar. Sólo les cuento que el scriptengine Rhino viene incluido con Java6 y que para empezar a usarlo bastan una pocas líneas de java embebido en algún programa que hagamos con GX.

Aquí un ejemplo para probar en un procedure.

Primero ponemos algunas funciones javascript en una variable:
&jscript = 'function f1(parm1)' + newline() +
'{' + newline() +
' //aquí el código' + newline() +
'}' + newline() +
'function f2(parm1)' + newline() +
'{' + newline() +
' //aquí el código' + newline() +
'}'

Luego el java para instanciar el scriptengine:
java javax.script.ScriptEngineManager manager = new javax.script.ScriptEngineManager();
java javax.script.ScriptEngine engine = manager.getEngineByName("javascript");

Y luego cargar nuestras funciones javascript e invocar una de ellas:
java try {
java engine.eval([!&jscript!]);
java javax.script.Invocable invocableEngine = (javax.script.Invocable) engine;
java Object ob = invocableEngine.invokeFunction([!&funcionJS!],[!&parm!]);
java [!&out!] = ob.toString();}
java catch(javax.script.ScriptException e){java System.out.println(e);}
java catch (java.lang.NoSuchMethodException e) {e.printStackTrace();}

Las variables &funcionJS, &parm y &out corresponden al nombre de la función, un parámetro y el retorno, respectivamente.

Un problema se nos puede dar con el pasaje de parámetros. En este ejemplo sólo tenemos la posibilidad de pasar uno, y tiene que ser string. Pero si pasamos un string JSON, en el javascript podemos evaluarlo e instanciar un objeto con el que podemos trabajar (podría ser una lista de parámetros, por ejemplo).

Algunas cosas entretenidas que se pueden hacer:

• usar otras classes java desde un script, por ejemplo conectar a una BD (JDBC)
• compilar a bytecode java, antes de invocar
• quién sabe qué más!
  

Bueno, un saludo a todos y hasta la próxima.-

Modificando el WorkWith en la XEv1

Primero que nada, para que no se pierda la costumbre y aunque parezca tarde, un feliz y próspero 2009 a los genuxianos de Chile.

Parece que durante el 2008 todos estuvimos bastante ocupados, lo que se tradujo en que no organizamos actividad alguna y ni siquiera escribimos en el blog.
La falta de participación y de entusiasmo, seguramente tiene que ver también con la utilidad que el GUGXChile brinde a los genuxianos en su labor diaria y que hasta ahora no ha sido tal. O sea, falta que esto sea una instancia de colaboración más efectiva.
Puede haber otras cosas, pero ahora quiero ir al motivo del post.


Desde GeneXus 9 contamos con la posibilidad de trabajar con Patterns, que por decirlo de una manera simple se trata de "moldes" o "plantillas" inteligentes con las cuales hacemos automáticamente un montón de trabajo que normalmente haríamos "a mano".

Probablemente el pattern más utilizado es el WorkWith que viene con GeneXus, por lo cual asumo que muchos habrán experimentado un poco creando algunas transactions y viendo como, en segundos, se obtiene una aplicación completa con las pantallas de "trabajar con" y los tabs con vistas según las relaciones dadas por los atributos en las transactions.
A pesar de toda la maravilla, es probable que muchos (fue mi caso) hayan echado de menos alguna forma de control de acceso y permisos y quizás otras cosas más.
¿Por qué ARTech no lo hizo más completo? ¿Será que luego viene otra versión mejorada?
No. La idea es que cada uno haga sus propios patterns y el WorkWith es sólo un buen ejemplo de la potencia de esta herramienta.

ww2
Quise embarcarme en este tema, pero no creando un pattern desde cero, sino que modificando el WorkWith de Artech (GXXEv1 Beta1). A partir de ese trabajo preparé una versión que denominé ww2 y que está disponible en GXOpen.
Esta versión considera:
- Creación de transacciones de Usuarios, Módulos y Permisos.
- Procedimiento de inicialización del usuario admin.
- Procedimientos de validación de accesos y permisos.
- Login en el webpanel Home.
- Adición de rutinas de seguridad en los webpanels generados.

Vista del Login en webpanel Home

La funcionalidad esperada es algo así:
- el usuario sólo tendrá disponibles, en el menú, aquellos módulos para los que está registrado
- en la pantalla de "trabajar con" sólo tendrá disponibles las opciones según permisos (Insert, Update, etc.)
- el usuario podrá tener accesos y permisos individualmente o por formar parte de un grupo de usuarios

Vista del Menu en webpanel Home

Modificar el WorkWith
No pretendo detallar en extenso los cambios, pues sería demasiado largo y la idea es que descubran cosas por si mismos, con un poco de guía, mirando los archivos XML y DKT del ww2.

Modificar el proyecto CSharp
En el caso del WorkWith, los fuentes vienen con el Platform SDK.
Esto es un poco avanzado y orientado a programadores CSharp, más que a usuarios GeneXus.
En el caso del pattern ww2, fue necesario tocar el código csharp para cambiar el nombre de WorkWith a ww2.

Modificar el archivo de recursos
El archivo de recursos es un xml con la definición de los objetos que se consolidan en la KB la primera vez que se aplica el pattern.
Para agregar objetos al archivo de recursos basta con hacer una exportación, abrir el xpz y copiar el elemento Object que nos interesa.
De esta forma agregué las transactions y procedures al archivo de resources del ww2.

Modificar los templates DKT
Los templates DKT son archivos de texto con una programación CSharp embebida que GeneXus interpreta al momento de aplicar el pattern. La ejecución de cada template retorna las partes (Events, Variables, etc.) de los nuevos objetos.
Podría decirse que se trata de una consolidación (importación) especial, no desde un xpz, sino que desde la interpretación de los templates.
En estos templates se puede apreciar con facilidad, por ejemplo, las partes del código GeneXus que son fijas y aquellas que se construyen dinámicamente con la interpretación del csharp.
Un buen ejemplo es el código de la rutina Permissions en el archivo GridEvents.dkt del pattern ww2.

Eso por ahora.