Convertir de Theme a Design System


Durante años, los Themes fueron la forma clásica de definir la estética de una aplicación GeneXus. Colores, fuentes y estilos centralizados, pero rígidos. Hoy, con Design System Objects (DSO), GeneXus da un paso enorme hacia la consistencia y la evolución visual controlada.

Migrar de Theme a Design System no es solo un cambio técnico: es adoptar una mentalidad de diseño unificado. El Design System permite definir tokens reutilizables (colores, tipografías, espaciados) y componentes que se adaptan automáticamente a la plataforma —web, mobile o ambas—, mejorando la experiencia de usuario y facilitando el mantenimiento.

En este proceso, lo que vamos a cambiar incluye:

  • Reemplazo de Theme por Design System.

  • Creación de una nueva MasterPage moderna.

  • Adopción del Editor Abstracto para una edición más limpia y visual.

  • Implementación de un diseño responsive para adaptarse a todos los dispositivos.

  • Limpieza de recursos no utilizados (Themes y MasterPages viejas, etc.).

  • Pasaje a valores por defecto de la mayoría de las clases.

  • Pasaje a valores por defecto de propiedades en los objetos GeneXus.

El proceso de conversión tiene que ser gradual y debe garantizar que la aplicación continúe funcionando en todo momento. Dado que la KB tiene más de 3.300 objetos con pantallas web, no se busca un cambio radical, sino una transición paulatina y controlada.

El proceso de conversión suele implicar las siguientes etapas:

  1. Comenzar por los WebForms de transacciones que usan patterns, asegurando que los nuevos formularios sean compatibles con el Design System.

  2. Continuar con los objetos generados automáticamente por los patterns, verificando su adaptación al nuevo esquema visual.

  3. Luego avanzar con el resto de las transacciones no basadas en patterns, migrando gradualmente sus layouts al nuevo DSO.

Finalmente, actualizar los WebPanels personalizados, revisando estilos, clases y propiedades para alinearlos con el Design System.

Defincion de indicadores


Para poder medir el avance del proyecto, defini un indicador simple para usar era contar la cantidad de objetos que tienen formiulario web que usan el nuevo DSO.

Para colaborar con la conversion, tenemos programas que detectan clases referenciadas en los objetos, que no existen en el DSO. 

Estudio del alcance del proyecto.  Que cambiar y cuando


Tambien hice programas con ayuda de IA, que identifican objetos por módulos y obtienen las siguientes caracteristicas. 

  • FullyQualifiedName
  • Type
  • MasterPage
  • ParentType (si el objeto esta en un FOLDER / MODULO O ES GENERADO POR WORKWITH)
  • Theme (SI ESTA EN BLANCO, TOMA EL DEFAULT)
  • WebUX (SI ES SMOOTH O NO)
  • WebFormDefaults (SI ES RESPONSIVE O NO)
  • FormLayout (UNANIMOTEMPLATE O CARMINE TAMPLATE)
  • FormEditor (HTML O ABSTRACT) Si el form es DEFAULT, no tiene nada
  • RulesDefault (si es workwith, dice si las rules no perdieron dinamismo)
  • EventsDefault (si es workwith, dice si los eventos no perdieron dinamismo)
  • ConditionDefault (si es workwhith, dice si las condition no perdieron dinamismo)
  • FormDefault (si es workwith, dice si el form, no perdio el dinamismo)
  • Description (descripcion del objeto)

 
Con todo esto, pudimos analizar que tanto teniamos para cambiar, cuantos objetos podiamos cambiar por sprint y que tanto ibamos a tener que trabajar para lograr el objetivo. 

Propiedades involucradas en el cambio. . 

Las propiedades que afectan este cambio, son varias, y tienen diferentes niveles de jerarquía. 
Tuve que hacer un diagrama para poder entenderlo . 


Conclusiones

Lo que al principio me pareció que era un cambio no tan grande, luego de realizar la evaluacion, termino siendo mucho mas grande y complejo de lo que me parecía. 
Nos va a exigir automatizar varias de las etapas de y vamos a dedicar recursos para la prueba de todas las pantallas. 
Si bien el proyecto no esta terminado, el resultado obtenido hasta el momento, es bueno. Y si bien la parte de UI no es mi fuerte, si entiendo que nos deja con un sistema mucho mas fácil de mantener. 

Algunos links interesantes

GeneXus Theme y GeneXus DSO 
Que es un DS?
Mitos de DS 

Comentarios

Publicar un comentario

1) Lee el post
2) Poné tu opinión sobre el mismo.
Todos los comentarios serán leidos y la mayoría son publicados.

Entradas más populares de este blog

Migrando de GeneXus 9.0 a GeneXus X.

Imagen
La idea de este post es comentar algunos de los problemas que he encontrado migrando desde Genexus 9.0 a GeneXus X. Tiene también algunos tips que pueden hacer mas fácil la vida (al menos la mia). Los pasos que hice fueron: 1) Copiar el directorio de la KB para guardar en caso que pase algo. Borrar de la KB el directorio de los modelos (los DATA00x). Esto es para asegurarme que no me queda ningun fuente viejo, ni ninguna dll, jar, etc de la versión anterior. 2) Entrar con GeneXus 9.0 a la KB y borrar todos los modelos que no se utilicen. Esto se hace con File/Delete Model estando en diseño. Conviene borrar el modelo de Backup (si existe) pues acelera la conversión. 3) Renombrar el domino Boolean si existiera y ponerle Boolean90. En GeneXus X Boolean es un tipo de datos nativos y si existe un domino Boolean (como el que usa el Pattern WorkWith, se arma lio). 4) Borrar todos los objetos que no se utilicen y los que sean WIN. Este paso no es indispensable, pero es muy saludable. Puede a...
Leer más

La nefasta influencia del golero de Cacho Bochinche en el fútbol uruguayo

Imagen
Esta teoría no es mia, sino que se la escuché por primera vez a Andrés Acosta. Varias generaciones de niños en Montevideo, crecieron viendo un programa de televisión llamado Cacho Bochinche, donde había un juego donde habia que patear penales a un arco con un golero de goma. La falla fundamental del mismo, es que en vez de premiar a quienes metian goles, se premiaba a quienes logran pegarle un pelotazo al golero y tirarlo al suelo. O sea, quien pateaba en forma mas burda y fuerte, era el ganador. Para complicar mas la situación, muchas veces cuando un niño no lograba voltear al muñeco, el animador del programa (el inefable Cacho de la Cruz que hacía de juez), le pegaba o empujaba al golero para tirarlo al suelo y de forma de dejar contento al niño que estaba haciendo pucheros. Por lo tanto se promueven varios valores, que han logrado calar muy profundo en las generaciones de niños telespectadores: a) Es bueno patear fuerte y al medio b) Tirar a colocar es de maricones c) El golero es ...
Leer más

Aplicación monolítica o distribuida?

Imagen
En los últimos tiempos, hemos escuchado muchas opiniones sobre cómo es conveniente diseñar nuestras aplicaciones, desde el punto de vista de su arquitectura en la ejecución.  Históricamente las aplicaciones eran monolíticas (una aplicación que se instalaba en una computadora y hacia todo lo que necesitaba) y en forma más recientes se esta optando por hacer aplicaciones distribuidas en varias computadoras, dividas en servicios independientes (algunos lo llaman microservicios). Al ser tan variadas las aplicaciones que realizamos, es claro que no hay una solución optima para todos los casos, sino que tenemos que adoptar (y adaptar) la arquitectura que mas nos convenga para cada caso. También hay que entender que entre una aplicación monolítica y una aplicación totalmente basada en microservicios hay una gran variedad de combinaciones posibles, pues no hay que hacer binaria la elección. El problema.  Es una realidad, que los sistemas de información cada día abarcan más...
Leer más