GeneXus Wish List - v2019
Voy a escribir una lista explicada de las opciones que me gustaría contar en GeneXus 16. Hay una versión en el Wiki de la comunidad GeneXus, donde pueden agregar deseos.Special Build
Los objetos hoy tienen muchas opciones relacionadas con el build. Para no sobrecargar el menú básico, sería mejor tener una opción Special Build con un submenú con las siguientes opciones (agrupa las opciones relacionadas con el build, no usadas muy frecuentemente)
Rebuild
(como la opción Rebuild de hoy)
Build this & Compile Mains (solo los que incluye a este objeto)
Hoy pasa muy a menudo que se hace un build with this only, y "no me compila el objeto".
El problema es que al hacer el build de dicho objeto, se genera el archivo fuente, y luego se compila el startup object, y si no contiene al archivo no se toma en cuenta dicho objeto.
Seria bueno tener una opción que fuera "Regenerate this objects and Compile all main that contains this object" (tal vez es un poco largo para el menú).
Build Object and Referenced
Hacer un build de un objeto y todos los referenciados por el (no todo el árbol, solo un nivel)
Build Object and Referred
Hacer un build de un objeto y todos aquellos que hacen referencia a este objeto. ( no todo el árbol, solo un nivel)
//TODO: comentario
Para poder documentar algún ajuste o mejor que quiero hacerle al objeto poder comentarios de la forma:
//ToDo: Ajustar variables.
Tener una forma de acceder rápido a la lista de objetos que tienen comentarios de ese tipo y dejarlo como lista de trabajo pendientes.
El especificar da un warning cuando hay un objeto con un comentario //ToDo:
Es una buena forma de documentar y poder gestionar la deuda técnica en la KB.
Nuevos controles al especificar.
Sería deseable que al salvar o al especificar un objetos, se hicieran controles adicionales (opcionales) para optimizar los objetos y el código generado.
Variables no usadas.
Al especificar un objeto, dar un warning si tiene variables no usadas.
Atributos sin dominios.
Al especificar una transacción, dar un warning si el atributo no está basado en un dominio.
Variables no basada en atributo o dominio.
Al especificar un objeto, mostrar un warning si la variable no está basada en un atributo o un dominio.
Objeto demasiado complejo.
Permitir definir criterios de complejidad y dar warning cuando se especifica un objeto demasiado complejo (largo, ciclomatica, demasiadas reglas, etc)
Build with this only para External Objects.
Poder tener la opción de generar el fuente de un External Object en solitario, sin tener que especificar a los programas llamadores.
Refactoring automático.
En las herramientas modernas de edición de código, tiene la posibilidad de realizar refactoring automático de ciertas operaciones comunes, que hacen más fácil programar. Seria bueno que GeneXus cuente con alguna de ellas.
Renombrar variables.
Elegir una variable en el diálogo de variables, y poder renombrarla en todos los lugares que se utiliza, dentro del objeto (form, rules, codigo, properties, patterns, etc).
Extraer procedure de código.
Estando en el editor de Eventos/Procedures permitir elegir parte del código y generar con eso un procedure.
Crear la regla de parm() en forma automatica, con las variables que solo estan en la parte derecha de las asignaciones o son usadas para filtrar, como parametros de entrada
Las variables que son asignadas solamente, como parametros de salida (o de entrada salida, si son usadas además fuera del código seleccionado).
Esto ya lo hace muy bien la extensión LsiExtensiones (pero sería bueno generalizarlo y ampliarlo)
Borrar un atributo que no esta en ninguna tabla.
Un atributo que no esta en ninguna tabla, no deberia ser usado en ningun objeto, ni tener ninguna referencia.
Deben cambiarse todas las referencias al mismo, cambiando el tipo de datos de los elementos de SDT, Variables, DV, por el dominio de dicho atributo (si lo tiene) o por el tipo basico del atributo si no tiene dominio.
Esto ya lo hace a medias la extensión KBDoctor (perro seria bueno generalizarlo y ampliarlo).
Quitar un parámetro de un objeto.
Dado un objeto que necesito sacarle un parámetro, me deja elegirlo y luego recorre todos las referencias al mismo y le quita dicho parámetro.
Unificar parámetros en SDT
Permite seleccionar un conjunto de parámetros (todos de entrada o todos de salida) y los agrupa en un SDT.
Crea el SDT con campos con el mismo nombre que los parámetros.
Genera dos subrutinas que permiten pasar del SDT a las variables que hoy existen y otro que pasa de las variables al SDT.
parm(in:&DocumentoTipo, in:&DocumentoID, out:&Habilitado)
&DocumentoSDT
.DocumentoTipo
.DocumentoID
y se cambia la regla por
parm(in:&DocumentoSDT, out:&Habilitado)
&DocumentoTipo = &DocumentoSDT.DocumentoTipo
&DocumentoID = &DocumentoSDT.DocumentoID
y todos las llamadas se cambian de
if DocumentoHabilitado(&Tipo,&Doc)
...
endif
por
&DocumentoSDT.DocumentoTipo = &Tipo
&DocumentoSDT.DocumentoID = &Doc
if DocumentoHabilitado(&DocumentoSDT)
..
endif
Agregar un parámetro.
Permite elegir un objeto y agregarle un parámetro (nombre, tipo , y si es IN OUT o INOUT .
Recorre todas las llamadas a dicho objeto, agrega una variable en la llamada con el nuevo parámetro y también un comentario
//TODO: Parameter XXXXX added by refactoring.
Recorrer todos los lugares en los cuales el objeto es referenciado y proponer el cambio de código agregando el parámetro poniendo en su lugar una variable con el nombre del nuevo parámetro.
Search and Replace.
Poder elegir un conjunto de objetos, y buscar en los objetos y reemplazar. Hoy el search está basado en el indexado de Lucene, que por motivo de performance tenemos que deshabilitar, pues afecta muchísimo al desarrollo en KB grandes.
Es bueno tener un buscador (que tenga opción de buscar expresiones regulares) y que permita hacer cambios.
Se podría pensar en buscadores especializados como por ejemplo, cambiar el tipo de datos de la variable &Moneda de Char(2) a Char(3) en todos los procedures de la KB.
Tambien estaria bueno poder buscar por propiedades (funcionalidad que hoy existe, pero no funciona correctamente) . Por ejemplo, Buscar todos los objetos que tengan la propiedad Encrypt Url parameters = SiteKey.
Y luego poder hacer un build all con dichos objetos.
Opción del menú para ir al folder de instalación de Genexus.
Es común tener que ir al directorio de instalación de Genexus, para ver determinadas cosas, como archivos de GAM, copiar extensiones, User Controls, etc.
Cuando se tienen muchas versiones de GeneXus instaladas, pues se está desarrollando en varios proyectos con diferentes versiones, es común confundirse. Seria bueno tener una opcion en el menu, que permita abrir el directorio de la instalación de Genexus.
Opcion del menu, para hacer un GeneXus /Install
Cuando se instala una version nueva de Genexus, es común tener que hacer una GeneXus /install. Esto es algo que no es trivial para algunos desarrolladores GeneXus y sería bueno poder hacerlo desde el menu, haciendo que GeneXus se cierre y ejecute un Genexus /install.
Ejecutar GeneXus sin permisos de administrador.
Sería bueno lograr que Genexus pueda ejecutar sin permisos de administrador. Simplifica mucho el proceso de instalación y su ejecución.
View Data - Prueba de Objetos GeneXus.
Algo que facilita mucho el desarrollo, es poder probar en forma fácil el funcionamiento de un objeto.
En este sentido, estaria bueno poder probar un Data Provider, por ejemplo teniendo una opción View Data, en dicho Data Provider, que muestre como máximo 100 registros devuelto por dicho data provider.
Si el DP tiene parámetros, pide valores para dichos parámetros en forma iterativa y luego muestra los datos de dicho data provider.
Un esquema similar puede usarse para Business Component, Data Selectors, For each, etc.
Mejorar la forma de almacenar referencias entre objetos en la KB.
La forma en que hoy se almacenan las referencias entre objetos, no es suficientemente detallada. Se necesita tener un tipo de referencia, y tal vez un lugar de la referencia, en donde se explicite qué tipo de referencia se tiene y en qué parte del objeto se referencia.
Por ejemplo las referencias a una transacción, hoy son similares:
for each Transaction1
msg
endfor
&Trasaction1.Clave=333
&Transaction1.Save()
&Link = Transaction.Link()
y a pesar de ser referencias a una misma transacción, tienen todas un peso diferente en cuanto a su uso. Sería bueno poder ver dichas diferencias y poder filtrar por los diferentes tipos.
Eliminar el WinForm de las transacciones
Por default, no mostrar el WinForm en transacciones y no mostrar WorkPanels.
Trabajar con KB.
Tener un "Repositorio de KB" que sea un listado de todas las KB que tengo agrupadas por los criterios que me interesan.
Poder trabajar con dichas KB, teniendo tareas como :
- Borrar una KB (borrar la KB, la base de datos de la KB, la base de datos generada por la KB (opcional), todos los archivos de dicha KB.
- Comprimir la KB
- Respaldar la KB
- Renombrar la KB
- Reparar la KB
- Mover la KB a otro directorio
- Abrir la KB (con la version / instalación de GeneXus que corresponda, puede ser diferente a otras KB del repositorio)
- etc.
Re-establecer Ancho de columnas
En todas las grillas del IDE de Genexus que permitan cambiar el ancho de las columnas, tener una forma de restablecer el ancho original de las mismas. Hoy es muy común que el ancho de las columnas quede mal (no se ve correctamente el contenido de las columnas) y volverlo al estado inicial es bastante difícil.
Instalador de GeneXus / Gam Platform / GXFlow que funcione por línea de comandos.
Para poder automatizar las instalaciones de GeneXus es indispensable que se puedan bajar nuevas versiones, ejecutar los instaladores desde línea de comandos. Hoy no funciona correctamente y no está documentado cómo hacerlo, lo cual dificulta la instalación de nuevas versiones.
Lo mismo es válido para la instalación de User Controls, Extensiones, Patrones, etc. Todo debe poder instalarse por línea de comando, para poder hacer scripts que faciliten la instalación.
Buen día Enrique. Muy buenas ideas, sumo un par a ver que les parece y después las sumo a la pagina en la wiki:
ResponderBorrarPoder elegir Tomcat: Teniendo varias KBs o varios tomcats(instalados) en la misma pc, al momento de configurar las propiedades de la KB si se configuran las propiedades del tomcat a uno distinto al default no funciona correctamente. Creo que lo ideal sería tener igual que cuando tenemos como generador .NET que podemos elegir la version del IIS. Hoy en día el WA que encontré es modificar el Regedit a mano dejando como entrada de tomcat de mayor version el que quiero utilizar (si tengo el 7 y el 8 instalado toma por defecto el 8, si quiero usar el 7 en el regedit modifico el nombre de la entrada del 8 dejandola como 0_8.0)
Poder diseñar empty state layout (este ya lo pase por IT hace rato, veamos si se le puede dar fuerza): En SD contamos con la posibilidad de tener muchos layouts por grid, creo que estaría genial poder contar con un layout que sea el que se muestre cuando la grilla no tiene datos para mostrar, tanto para SD como Web.
Comentarios con tus ideas:
// TODO: Para lograr ésto hoy puedes hacer una categoria dinamica con las propiedades Query = // TODO y Show in model tree en True. De esta manera te queda en el KB explorer la categoria abajo de main con todos los objetos que tienen el // TODO, si me encantaría que se agregue la propiedad en la categoría para poder decirle que me avise por output (Ej. " Warning - The object &pgmname is marked " )
Contra todas las ideas que son borrar atributos o modificar regla parm agregaría las restricciones necesarias para asegurarnos que no haya problemas de integración con otras Kbs, por ejemplo que no tengan la propiedad de Exposed As Web Service en True.
Que les parecen? Voy a ver si tengo mas.
Joaquin Delgado.-
Elegir el Tomcat - Esto lo queres en momento de deploy o para el desarrollo?.
BorrarYo desarrollo con un unico tomcat, y luego cuando genero el deploy, cambio de version. Como no uso mucho java ahora, puede que me este perdiendo algo.
Para WEB en la ultima version se tiene clases diferentes cuando la grilla esta vacia. Para SD puede necesitarse. Me parece una buena sugerencia.
//TODO - Es cierto lo que decis. Pero en KB grandes, lo que hago es deshabilitar el indice, pues enlentece muchisimo el salvado de objetos. Esto hace que aplicar patterns y demas, demore mucho. De cualquier forma, agregando el //ToDo al codigo, ya ayuda a luego buscarlo. Sera cuestion de encontrar la mejor forma de mejorarlo.
Creo que el borrar atributos, debe dar la posibilidad de hacerlo en todos lados.
Lo que si varias veces he necesitado, es una herramienta para controlar el API de mi KB. O sea, que revise si alguno de los objetos que expongo, tuvo algun cambio. Lo pueden afectar, cambio de nombre, cambio de modulo, cambio de tipo de dato de algun parametro, mas parametros, menos parametros, estructura de un SDT, etc.
El problema es mas complejo que no dejar borrar un parametro, y estaria bueno contar con una herramienta para manejar el API de la KB, a varios niveles. Por ejemplo, poder ver los servicios, las URL de los main, las URL de los objetos no main, los servicios creados por SD, etc.
Con el empty state quería darle un poco mas de funcionalidad que la clase.
BorrarPor poner un ejemplo pavo en Web: Tengo una grilla de mensajes a un cliente, nunca se le mandó nada o esta filtrada. Me muestra el empty state. Yo quisiera desde el IDE poder elegir el "empty grid layout" que sugiero para poder agregarle un botón para ir al alta del mensaje o cualquier funcionalidad o hasta un web component. Si creo que tiene que ser restrictivo en no poner otra grilla. Toda la sugerencia hoy en dìa se puede hacer, pero creo que sería mucho mas rapido para el desarrollador hacerlo como digo ademas de estandar, ya que cada uno chequea eso como quiere.
Agrego 3:
ResponderBorrar1.- Que en la definición de campos de las transacciones se puedan agrupar o colorear determinados campos según el grupo.
Esto porque cuando son muy grandes las transacciones se pierde la visibilidad de los campos y si permitiera ponerle color se visualizarían rápidamente.
2.- Que las compilaciones sean más rápidas.
3.- Hacer una búsqueda global de una cadena de texto en todos los objetos de la KB que la contengan, filtrando dichos objetos.
Walfred:
BorrarCon respecto a 1), he tenido necesidad de agrupar atributos, pues representan un "dominio estructurado", por ejemplo { FacturaImporte, FacturaMoneda }.
El importe sin la moneda, no tiene sentido, no puedo sumar Importes de diferentes monedas, no puedo comparar imortes en diferentes monedas, etc.
Me da la sensacion que el color, es solo algo visual y tal vez estemos necesitando algo un poco mas potente para esto. Tal vez el color es un buen paso inicial, aunque no sea lo optimo.
2) En la Beta, hay COMPILACIONES EN PARALELO!!. Para los modelos con muchos objetos main, la diferencia es notable. Paralelizando la compilacion, pasamos un ciclo de build all de una hora a unos 16 minutos (en promedio).
3) Concuerdo que se necesita un buscador global (que funcione bien).
Ya tenemos una búsqueda global. Lo que pasa es que no funciona bien. Enlentece mucho el desarrollo, si tenes muchas versiones, el indice crece innecesariamente, muchas veces no encuentra todo las apariciones de un texto en el codigo, etc.
O sea, es indispensable tener una forma de buscar en el codigo geneXus y muchas veces lo termino resolviendo, haciendo un export de los objetos en los que quiero buscar en formato xml y buscando con Notepad++ o algun buscador similar.
Gracias Enrique!
ResponderBorrarMe gustan tus sugerencias!