GeneXus M

Hace unos pocos días pude ver la presentación "Evolución de la arquitectura de GeneXus", por Germán Asiz, en el GX26, y me he quedado bastante contento por el camino que se está tomando, pues se trata de definiciones que dan inicio a una época totalmente nueva en GX, con unas posibilidades muy atractivas.

El caballito de batalla de esta nueva etapa va a ser, cómo no, una nueva versión de GeneXus, que entre otras cosas recoge un antiguo anhelo de cierto tipo de usuarios (me incluyo) y casi una "exigencia" de las nuevas generaciones: que el IDE se pueda instalar en cualquier sistema operativo.

Tal cual. Yo me apuntaré con alguna distribución Linux.

El nuevo IDE, GeneXus M, va a ser gratuito, liviano y Open Source -ya hicieron un prototipo basado en Atom- con todas las posibilidades de colaboración que eso lleva y con lo que se están sentando las bases para el advenimiento de una diversidad de iniciativas y herramientas que serán desarrolladas por la gente de GeneXus y también por terceros (si me quedara algo de tiempo para disfrutar este tipo de cosas, yo mismo trabajaría en algún proyecto así, algo basado en Eclipse, por ejemplo). Puede que en el futuro veamos, además de la evolución del clásico IDE de GX, otros exclusivos para determinadas plataformas o dispositivos.

Pongo énfasis en lo del IDE porque es lo que siempre nos entusiasma, no?. Pero claramente la cosa va mucho más allá, porque se sostiene en cambios a nivel de arquitectura de GeneXus que implican un desacople de componentes del GX que conocemos hoy -que es algo así como un solo bloque- y esos componentes en la nueva organización van a posibilitar nuevas formas de desarrollar y colaborar.
Va a ser interesante ver cómo vamos a trabajar con la capa de servicios de GeneXus (GXServices). Y cómo vamos a pagar por usarla. Porque este nuevo escenario también plantea la necesidad de revisar cuestiones de licenciamiento y de estrategia de llegada a muchos más desarrolladores, clientes y partners.

En toda esta historia hay algo que a mí me gustaría ver y no sé si realmente estará en planes de alguien. Se trata de un "desacople" un tanto particular: que la generación de la UI/UX esté por separado en generadores especializados y que, de paso, también sea posible que terceros desarrollen esos generadores. Es decir, por ejemplo, que podamos usar el generador Java tradicional de GX complementado con un generador de UI (Desktop, Mobile, Web o lo que sea) desarrollado por Simplifica o Dvelop. O con alguno que pueda desarrollar cada uno en sus "tiempos libres".

 Work With generado con el pattern wuiServices y template Angle

Esta idea me quedó dando vueltas de mi experiencia desarrollando wuiServices, un pattern WW muy sencillo que en vez de Webpanels generaba directamente Html y Javascript. Pues estando en eso te das cuenta de que si estás generando esos fuentes, ese código, tal vez lo que deberías estar desarrollando es un generador y no un pattern. 

Un generador de UI debiera trabajar a partir de un input desde el editor de formularios del IDE GeneXus, aunque también podría ser desde otro tipo de editor en una herramienta desarrollada por terceros. La salida de estos generadores serían "Vistas" naturalmente ajenas a la implementación de las lógicas de negocio o de acceso a datos, pero integradas totalmente a la solución desarrollada.
Una cuestión complicada de esto podría ser la generación de código de eventos, pero podría darse casos en que simplemente vamos a querer escribir eventos del lado cliente por nuestra cuenta y serían nativos del generador.

Me gusta pensar que esa separación de generador backend y generador UI podría dar paso a una buena oferta de soluciones y con ello una mejora interesante de la competitividad de GeneXus.

Esto pinta bien, me gustaría participar de cosas así y además tengo un buen presentimiento con el 2017: de seguro va a ser mejor que el 2016.

salu2!!!

Scripting GX Java 8 Nashorn

A riesgo de parecer reiterativo, he querido hacer una actualización del tema de scripting Java, esta vez con GeneXus Xev3, Java 8 y el -no tan- nuevo engine Nashorn, que reemplaza al anterior Rhino.
Nashorn cuenta con algunas características que lo ponen por sobre su predecesor: mejor performance, posibilidad de invocar Java desde Javascript y viceversa, cuestiones de seguridad, etc..

El ejemplo que ahora les traigo es bastante sencillo y no pretende ahondar en cuestiones tan avanzadas, sino ser una guía inicial. De ahí en adelante depende de ustedes.
Por decir algo, alguien podría querer extender con Javascript las clases que genera GeneXus en un proyecto cualquiera...

Pero bueno, nuestro caso se trata de lo siguiente: tendremos un webpanel que llama a un procedure pasándole un pequeño script por parámetro. El procedure llamado es el que instancia el engine Nashorn y ejecuta el script.
Por su parte, el script, es una función que tiene su propia llamada a otro procedure gx, el cual hace una lectura a la tabla Product y retorna un string.

Webpanel testNashorn

El webpanel sólo cuenta con un textblock y un botón asociado al evento Enter, en el cual ponemos la llamada al procedure jsEngine, pasando el script a ejecutar.

Event Enter
 
 //el script a ejecutar: una función que invoca el método "generaMsg" y retorna un texto
 &script = 'function mainFunc() {' + newline()
 + '    var myMsg = jsEngine.generaMsg("hola");' + newline()
 + '    return myMsg;' + newline()
 + '}' + newline()
 textBlock1.Caption = jsEngine.Udp(&script)
 
EndEvent

Procedure jsEngine

En el procedure jsEngine se pueden distinguir dos secciones de código: la primera es donde usamos el truco para insertar un método público generaMsg a la clase java jsengine que GeneXus genera a partir del procedure. Aquí es donde ponemos un llamado a nuestro segundo procedure generaString.
En la segunda sección va el código de instanciar el engine Nashorn y ejecutar el script preparado.

//todas las variables son VarChar(1K)
parm(&script,&return);

//Sección1: iniciamos "cortando" el java que genera GX
java     privateExecute2();
java }
//para poder insertar un método "generaMsg", que luego invocaremos desde el javascript
java public String generaMsg(String msg) {
java     [!&tmpString!] = msg;
//acá podemos poner una llamada a otro procedure, en este caso al proc "generaString"
&tmpString = generaString.Udp(&tmpString)
java     return [!&tmpString!];
java }
java private void privateExecute2( ) {

//Sección2: instancia del engine y la invocación
java try {
java     javax.script.ScriptEngineManager m = new javax.script.ScriptEngineManager();
java     javax.script.ScriptEngine ngNashorn = m.getEngineByName("nashorn");
java     ngNashorn.put("jsEngine", this); //pasamos el objeto actual al engine
java     ngNashorn.eval([!&script!]); //hacemos eval del script
//invocamos la function "mainFunc" y manejamos el resultado
java     Object result = ((javax.script.Invocable)ngNashorn).invokeFunction("mainFunc");
java     [!&return!] = result.getClass().getName();
if &return = !"java.lang.String"
 java [!&return!] = result.toString();
endif
java } catch(javax.script.ScriptException exc) {
java     [!&return!] = "Error evaluating the script: " + exc.getMessage();
java } catch(NoSuchMethodException exc) {
java     [!&return!] = "Error evaluating the script: " + exc.getMessage();
java }

Por cierto que estas cosas se podrían implementar como un External Object y no hacer esta mezcla de código GeneXus y Java. Pero insisto en hacerlo de esta forma, porque así basta con pegar el código en un procedure y nada más, lo que resulta ser bastante práctico y sencillo, y favorece que el usuario gx se anime a probar sin mucha complicación.

Procedure generaString

En este proc, simplemente, concatenamos algunas cosas al string recibido y lo retornamos. Nótese que se debe crear una transaction con atributos ProductId y ProductName, y ponerle algún dato a la tabla.

//todas las variables son VarChar(1K)
parm(&inString,&outString);

for each
 &ProductName = ProductName
 exit
endfor
&outString = &inString + !", qué tal: " + &ProductName

Resultado

Con todo listo, sólo falta hacer Build y ejecutar el webpanel. Click al botón y ya está. Les dejo una vista del webpanel a modo de "evidencia".

Espero que esté lo suficiente claro el ejemplo, que lo corran y que se animen a hacer otras pruebas. Y, claro, a ir pensando cómo usar este tipo de cosas en sus proyectos de la vida real.
salu2!!!

Editor Abstracto y posibilidades de Extensión

Me ha tocado trabajar en un pequeño proyecto con GXXEv3 y hasta el momento me he sentido bastante cómodo y pensando que ya voy a ir dejando de lado la Ev2, para las cosas que se vengan en lo inmediato.

Pero no voy a entrar en detalles de eso, sino en un tema que me da vueltas desde hace un tiempo y que me vuelve cada vez que veo el editor abstracto de formularios en la Ev3: ¿será que GeneXus se encamina a proveernos de alguna nueva posibilidad de extensión?

Por que si tenemos un editor abstracto, el paso siguiente podría ser alguna forma de exponer los eventos y que, derechamente, usemos herramientas provistas por terceros para el frontend web. O sea, algo así como generadores de interfaz web -con sus propios editores y otras herramientas- basados en cualquiera de los frameworks y librerías javascript que andan por ahí y que proveen tantas posibilidades.
Estos generadores que me estoy imaginando podrían integrarse a GeneXus de forma que el analista siga creando webpanels y transactions casi tal como se hace hoy. Al momento del build se dispararían tareas de generación y al ejecutar todo estaría a punto.

Una gran oportunidad se abriría para las opciones de integrar diseños completos provistos por terceros, a diferencia de lo que puede implicar hoy eso con el Theme Editor.

Ya me estoy viendo a los actuales proveedores de patterns y otras cosas, y a unos cuantos emprendedores, que de seguro aparecerían, preparando una variada oferta de productos que nos vendrían bastante bien para cuando querramos presentar prototipos a nuestros clientes esperando que al finalizar la reunión nos lancen un "dónde firmo?".

AngularJS, Ember, Backbone, etc.. Frameworks MVC, librerías, desarrollo orientado a componentes, en fin, un mundo de cosas que podrían complementar lo que hoy hacemos con GeneXus y que sin duda nos haría más competitivos.

Bueno, seguramente no sería tan simple implementar algo así. Tal vez también haya otras consideraciones políticas o comerciales que uno no se imagina.
Pero soy optimista y, quién sabe, de pronto no estoy tan lejos.

salu2!!!