Módulos en Genexus

En las últimas semanas, trabajé en la modularización de una KB grande, un proyecto que aun no finalizó.

Esto me llevo a reflexionar un poco sobre el estado actual de los módulos en GeneXus.

Mis reflexiones están basadas en la experiencia de trabajo de modularizacion algunas KB chicas en GeneXus 15 y una KB grande en Evolution 3. Faltarian varias mas para sacar conclusiones mas generales, pero creo que el intercambio de ideas de como se usan los módulos es necesario.

Para que sirven los módulos? 

Uno de los problemas que tienen los módulos, es que sirven para mucha cosas diferentes, lo cual ha hecho que se pierda un poco el foco hacia donde hay que seguir desarrollándolos.

Pueden servir para
* Entender mejor la KB
* Ayudar en el mantenimiento de la KB
* Distribuir el desarrollo entre varios integrantes o grupos
* Hacer mas fácil el Deploy de la aplicación
* Unir mas de una KB
* Distribución de binarios e interfaces.
* Hacer mas rapido el proceso de desarrollo

y algunos temas mas.

El tener tantos puntos fuertes, ha hecho que sea difícil enfocar la evolución de este objeto,

Por ejemplo, al ver las charlas de los Encuentros GeneXus anteriores, se ve un énfasis muy importante en la etapa de distribución de módulos como binarios (como hacen hoy GAM, GXFlow, etc), haciendo menos hincapié en los otros puntos.

Me parece que tanto el IDE de GeneXus, como los Patterns mas populares y GeneXus Server deberían avanzar para sacar provecho de lo que hoy tienen los módulos y también definir un plan de como van a seguir evolucionando estos objetos. Este plan, posiblemente exista y yo no lo conozco, pero me gustaria conocerlo.

En que se podría mejorar?

En el IDE de GeneXus:

* No hay una forma fácil de ver todos los objetos que pertenecen a un módulo.

* No es fácil saber a que módulo pertenece una tabla y tampoco saber si la tabla es publica o privada.

* Puedo exportar todos los objetos de un módulo, pero no puedo importar solo los objetos de un módulo de un xpz.

* Seria bueno poder seleccionar un módulo, y que hacer como que mi KB fuera solo ese módulo, sin ver mas que los objetos públicos de otro módulo.

* Es necesario, poder ponerle módulos a las tablas, en forma independiente de las transacciones, y también si son publicas o privadas. En muchas ocasiones, es bueno tener la transacción privada y la tabla publica.

* Hoy es obligatorio que una tabla sea publica, si tiene integridad referencial con tablas de otro módulo. Esto seria bueno poder cambiarlo.

* Si muevo un folder de módulo, no detecta que los objetos que estan dentro de dicho folder cambiaron de módulo, hasta que se realiza un build del objeto o de alguno que lo llame.

* Valorar en forma diferente las referencias a tablas. No es lo mismo un programa que actualiza una tabla fuera del módulo, a una transacción que hace un chequeo de integridad referencial. Hoy, debo poner la transaccion publica que genera la tabla como publica y dejar la tabla publica, para ambos casos, pero entiendo que seria mejor tratarlo en forma diferente.

GeneXus Server

* En el dialogo de Commit, se tiene el módulo, pero en el Update no.
Esto hace que si quiero actualizar objetos solo de un módulo, es bien difícil hacerlo.

* Una KB con módulos que tiene Build all exitoso, al querer subir los objetos cambiados, los Commits dan errores innecesarios al subir objetos en módulos.
Esto obliga a dividir el Commit en varios pasos.

* En los casos anteriores, al hacer el Update de dichos objetos, hay que también hacerlo en pasos, bajando primeros algunos y luego otros. En KB chicas esto es manejable. En KB grandes, es una perdida de tiempo enorme.

Patrones

* Solo como ejemplo, el WorkWith, genera un objeto ListPrograms, no se fija si los programas que llama son publico o privados, dando error en la especificación.  Seria bueno poder tener esto solucionado y no tener que borrarlo en cada KB. Se puede borrar en la KB y subir el cambio al server, pero cuando hago un Create KB from server, vuelve a crearse y a dar errores.

* (Para WW, WW+ y similares) Todos los objetos generados por una instancia, pertenecen al mismo módulo que el objeto en el que se basan dicha instancia. Puede ser interesante, que los objetos pertenezcan al mismo módulo de las tablas que recorren, pues sino, obligan a poner como publicas a tablas en forma innecesaria.

Si alguien llego hasta aquí, puede quedarse con la sensación que los módulos son un problema. En realidad, tienen una gran cantidad de virtudes y ventajas. Estas son solo algunas de las piedritas en el zapato, que pueden solucionarse.

Lo que pretendo es tratar de dar un poco de visibilidad al tema, para que los módulos sigan mejorando y puedan cumplir con todos sus objetivos.

Lo ideal, seria que dentro de unos años, podamos tener una KB que tenga solo mi módulo, subirlo al server y que se integre en un desarrollo mayor, sin tener que hacer  nada adicional. Y que se pueda distribuir en forma de binarios, con diferentes versiones, manejando tablas y reorganizaciones por módulos.