[Javier Ader]

Buenas. De un tiempo a esta parte estoy viendo que seria una buena mejora que existiesen campos virtuales: campos no asociados a un columna. La primero que se me ocurrió para lograr algo parecido es crear columnas virtuales a nivel de tablas y a estas asociarles algún tipo de datos, pero 1) creo que es a nivel conceptual el lugar incorrecto y 2) en el caso de los botones (la razón principal por la que los veo necesarios en estos momentos) si la fila es de solo lectura, o esta asociado a un vista, no se pueden disparar.
Ahora bien, el tema es que el tipo de campos dentro de una pestaña parecen generarse a partir del tipo de la columna subyacente, así que como mínimo, se debería tener que especificar el tipo “visual” del campo de manera extra (posiblemente también una forma de “logica predeterminada” o alguna forma de parametros que permita hacer variar el comportamiento del mismo a nivel pestaña). También, a nivel de creación de campos se debería especificar que la columna asociada puede ser opcional (a nivel de base de datos, la buena noticia es que AD_Field.AD_Column_ID puede ser null).
Imagino que a nivel de sql y metadatos es completamente posible. Los campos mínimos que deberían agregarse en AD_Field serían básicamente
-isvirtual char(1) (Y/N) : si este es Y, ad_column_id = NULL, aunque no tampoco sería completamente necesario (permitir que no sea null daría la posibilidad de delegar el manejo de una columna a un campo especializado; digamos por ej, para los CUITs)
type_virtualfield char(1) o type_virtualfield_id , como referencia a un tabla externa para mayor poder de “expansión”.

En cualquier caso, lo minimo que quisiese hacer es que el tipo permitido sea “boton”, así mediante el seteo de un callout poder disparar arbitrariamente cualquier cosa; por ej, distintos informes desde la misma pestaña (aca hay caso de uso https://www.libertya.org/comunidad/foro-libertya/8-desarrolladores/1202#1202 pero es fácil imaginarse muchos mas).
Se podría ir un poco más y permitir incluso Pestañas virtuales (e.d no necesariamente asociadas a un tabla), pero el grado de complejidad me parece que es mucho mayor.

Ahora, el mayor grado de generalidad que me imagino en este sentido es que incluso se puede delegar la lógica de representación visual a una clase “arbitraria”; en este sentido me imagino a la tabla type_virtualfield teniendo una columna class (obviamente, esta clase debería descender de una clase Swing o implementar una inteface que retorne un componente visual dado ciertos parametros, digamos getComponent(); me gusta mas esta última idea ).

Ok, todo muy lindo a este nivel; el tema debe venir a nivel de Swing y de las clases relacionadas con pestañas y campos a nivel visual. Si no me equivoco el punto de partida de toda está lógica es la clase MTab.

Bueno… es factible esto? Tiene mucho sentido? Seguro que es principalmente un “chiche” y no algo estrictamente necesario, pero creo que plantea un concepto de expansión interesante sin necesidad de caer en la complejidad de hacer forms desde cero.

[Antonio Calviño]

El enfoque que tomas creo que es incorrecto ya que la pestaña muestra los datos de la tabla. Entonces, allí debería estar el campo “virtual”: en la tabla. (ok, podría ser bueno poder ponerlo en cualquier nivel, pero como bien lo comentas, las pestañas (en realidad, los campos) dependen mucho de las tablas (en realidad, de las columnas)

Pegale una mirada a la definición de las tablas, en particular al campo: “Columna SQL”. Yo hace mucho que no lo uso y no recuerdo ya sus limitaciones, pero allí había algo para poner un campo “calculado” y podría permitir emular algo de lo que propones a nivel de tabla.

Otra cosa que podes mirar, para aprender mas funcionalidades “ocultas” es una ventana que si mal no recuerdo se llama “test” o algo así. Es una ventana que posee TODOS los tipos de datos posibles, incluídos algunos que no están en uso y algunos que no funcionan correctamente o que se usan solo para el diccionario (recordá que el propio diccionario está autodefinido en muchos lugares, por lo que todas las listas desplegables de definicion del diccionario, por ejemplo, son listas que están alli mismo)

Revisalo un poco y comentános que conseguis por ese lado.

Suerte!
Antonio.

[Javier Ader]

Buenas Antonio. Exactamente eso es lo que “cuestiono”; no entiendo a nivel conceptual porque tiene que haber un relación uno-a-uno entre campos y columnas de una tabla. Los campos son conceptos visuales, mientras que las columnas son un modelo de datos; llevando a cabo:
1) que la forma de visualizar una columna este especificado a nivel de modelo de datos y no a nivel de modelo visual [se podría dar el tipo visual acá, pero pudiéndolo redefinir si es necesario a nivel de pestaña; e.d una forma de tipo “default”]
2) obligar a que un “objeto” visual (campo en este caso) tenga obligatoriamente asociado un columna
pienso que se esta generando un “acoplamiento” innecesario entre el modelo de datos y el modelo visual (en este caso entre una Tabla y una Pestaña); e.d hay un mezcla de responsabilidades entre los dos modelos (el segundo depende del primero, pero no necesita depender tanto).
Eso es lo que genera que cuando uno quiere agregar un botón en una pestaña (concepto visual) tenga que modificar los metadatos a nivel de tabla (concepto de datos). En particular, esta limitación especifica se puede saltear “un poco” usando columnas virtuales a nivel de tablas (así por lo menos no te obliga a hacer modificaciones a nivel de base de datos; eso ya seria demasiado), pero como dije esto cae dentro de la lógica “read-only” a nivel de pestaña o de tabla en caso de ser una vista (si esta viendo una pestaña en modo solo lectura, no puede presionar los botones ya que pasan a estar desactivados).
Ok, reconozco que no debe tan fácil permitir la extensión que propongo ya que en muchas partes del código se asume que un campo esta asociado a una columna y su tipo visual es extraído de la definición de esta última (creo que todos estos datos se sacan indirectamente a partir de la vista AD_Field_v(t) al momento de crear la pestaña) y la verdad no se si vale tanto la pena.
Tal vez otra opción menos ambiciosa es que las pestañas no solo tengan asociado campos si no también alguna forma de subpaneles de complejidad arbitraria que permitan agregar controles visuales de manera tan directa a pestaña sin tener una relación directa con una columna, pero que se puedan visualizar dentro de las pestañas (visualmente algo similar a las pestañas incluidas). Obviamente estos subpaneles en general van a tener que mostrar datos o acciones relativas a la fila actual (por ej, disparar distintos informes asociados a la fila actual) o incluso relativas a nivel de pestaña (por ej, una forma de “búsqueda rápida” dentro de los filas mostradas en la pestaña; e.d sin necesidad de releer los datos desde la base de datos).

En cuanto a todos los tipos de datos que disponibles que mencionas creo que están dados en la clase DisplayType; después miro un poco más por ahí, pero esto aún sigue teniendo las limitaciones que menciono ya que este DisplayType esta asociado directamente a las columnas y no a los campos.

[Antonio Calviño]

Es correcto tu cuestionamiento, pero tal como decis, modificarlo ahora sería un tanto complicado. El modelo básico de ésto viene así desde El bisabuelo de Libertya. Si bien ya hemos hecho cambios grandes en la aplicación, éste en particular no es uno que sea suficientemente “grave” en el actual ciclo de vida del proyecto. Tal como decis, es un tema que no cierra, pero que en definitiva no genera problemas graves.
Si encontras la manera de agregar esa funcionalidad, con gusto se puede agregar a la lógica de la aplicación.

Saludos
Antonio

[Autor]

Entradas