Eliminar Styles de KB en GeneXus X.

En versiones anteriores de GeneXus, existian los objetos Styles que servían para uniformizar workpanels, webpanes y transacciones. Se definia la estetica en un solo objeto y la misma se replicaba en los objetos que los usaban. Eran útiles pero a partir de la version X los mismos no existen mas.

Si realizamos una migración de GeneXus 9.0 (o anteriores) a la X, los objetos convertidos mantienen una referencia a los Styles, pero como no existen como objetos, dicha referencia queda apuntando a objetos que  se almacenan en la "carpeta" TO BE DEFINED.

En general, joroban bastante poco, pero cuando se quieren subir objetos con dichas referencias al GXServer, dan problemas, pues el GeneXus Server no maneja los objetos Styles.

Si se quiere eliminar dicha referencia, se debe hacer:

1) Distribuir todos los objetos que usen Styles en la GeneXus X.
2) Descomprimir el xpz generado en 1) y salvar el xml.
3) En dicho XML, eliminar el texto:

<Property><Name>ObjStyle</Name><Value>497c0353-2904-4b7e-8711-d0ca41ac4460-ObjectsStyles_TTrnSEliminar</Value></Property>

donde el texto en rojo depende del nombre del style, y el identificador interno.
4) Volver a consolidar los objetos.

De esta forma, se eliminan todos los rastros de los styles en la KB.


Comentarios

  1. Consulta casi sobre el mismo tema.. si tenia aplicado patter ww con el THEME FANTASTIC en la version 9, ahora que migre a la version GX XEvo1, especialmente en los webPanel que estan WebComponen con TAB me trae colores distintos, afectados en el BackgroundColor y los Forecolor.
    hay una forma de llevar las clases o cual seria el mecanismo adecuado para que pueda tener el mismo look & Feel

    ResponderBorrar
    Respuestas
    1. Podes revisar que clases usabas en la 9.0 y volver a definirlas en la X.

      La forma mas facil de hacerlo es con alguna herramienta que permita ver cuales elementos tiene el html, uno bueno es con Chrome con la opcion Inspect element.

      Borrar
  2. Enrique, nos ha sido muy útil lo que venís posteando sobre cómo migrar a la X. Donde trabajo venimos cerrando la migración de una KB de 7400 objetos. Por ser una KB grande en un equipo de trabajo de muchas personas, organizamos el trabajo en forma iterativa, adelantando lo más posible en la propia versión 9, a medida que quemábamos cada etapa (abrir la KB en la X, conseguir que especifique, que cierren las navegaciones, etc.). La idea era ir haciendo la versión 9 "X-friendly", y dejar un log de los problemas que se podrían resolver una vez migrado.

    La mayoría de los problemas surgieron porque la X es más fuertemente tipada que la 9, y en general no perdona las desprolijidades que permitía la 9.

    Como anécdota, de los problemas encontrados, el que necesitó una solución más rebuscada fue el de las DYNAMIC CALLS en la función LINK: A diferencia de la 9, el generador XEV1, cuando se encuentra con una llamada tipo "link(&variable)", expande las dynamics calls, algo que no hacía en la 9 aún si estaba seteada la respectiva propiedad. No queríamos cambiar esa propiedad, para no perder información de llamadores y llamados. El problema es que a veces se generan fuentes demasiado largos. Eso provoca el error de compilación "code too large". No encontré forma de decirle al javac que pase por alto esto, los fuentes están topeados a 64k.

    Al final se trató con el siguiente work around: se cambió el link común por una llamada tipo "link(att:AttAuxiliar)".
    Basta con que AttAuxiliar sea algún atributo de una tabla auxiliar donde se vayan grabando URLs en forma temporal. Es rebuscado y poco eficiente, pero te saca del paso.

    Saludos!

    ResponderBorrar
  3. Mariano:
    Gracias por el comentario y me alegra que te sirva mi blog.

    Con respecto a tu wa sobre los call dinámicos, lo tomare en cuenta. Personalmente, prefiero no usar la expansión automática de calls dinámicos, pues en Kb grandes trae problemas.
    Prefiero agregar código de la forma

    call(&variable)
    If &i = &i+ 1
    Pgm1.call()
    Pgm2.call()
    .....Lista de todos los programas que van a ser llamados en forma dinámica
    Endif

    y no expandir los call dinámicos.

    De esa forma mantenéis visible el árbol de calls y las dependencias, y no agrega código innecesario en los exes. Tampoco tenes problemas al compilar.

    ResponderBorrar

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

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

Aplicación monolítica o distribuida?

Funcionalidades de GeneXus que vale la pena conocer: DATE Constants.