#34316
Javier Ader
Participante

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.