[Javier Ader]

Alguna vez ya plantie algo similar, pero me parece que mi planteo inicial era demasiado pretencioso (era basicaente permitir que a nivel de tab puedan exitir un numero de subtabs visualmente en donde aparecen las pestañas incluidas……). Lo que se me ocurre ahora es algo un poco mas simple pero que me parece que tendría mucha utilidad, principalmente para permitir que muchas extensiones requerida para una instalación en particular se puedan aplicar de manera mas “limpia” (principalmente, sin necesidad de modificar tablas en la base de dato, ni los metadatos que la reflejan).

Escenarios:
– se desea agregar varios botones de procesos en la pestaña Clientes; por ej, para disparar distintos informes
– se desea que al ver un producto se ver otros detalles relacionados indirectamente
– se desea que un campo sea el valor de una función de otros campos. No se me ocurre otro ej mejor; aunque los debe los debe haber: la tasa de conversiones de monedas se pueden ingresar como un ingresando “multiplicador” o como un “divisor”; en todas las conversiones, la tasa de division, jamas se usa; solo se usa la de multiplicación; la tasa de división es una columna que existe solo para permitirle al usuario agregar indirectamente (via un callout) la tasa de multiplicación…

Bueno, si uno mira el codigo, en el punto en que se crean los campos de una pestaña es en MTabVO.createFields. Lo que se hace es basicamente acceder a la definición del diccionario y generar una lista de objetos MFieldVO (van a parara en MTabVO.Fields), que son en principalmente un reflejo de las tablas AD_Field y AD_Column.
Lo que yo digo es una vez generada esta lista se puedan agregar otros campos (esto es, otros instancias de MFieldVO), pero que estos sean inferidos de otra tabla que no sea AD_Field, digamos AD_FieldExtend (aunque yo preferia que haya otra tabla itnermedia llamada AD_TabExtend; esto permitiria que dentro de una pestaña puede haber varias “extensiones” independientes). En particular estos AD_FieldExtend no tiene que tener el requerimiento de estar reflejados en una columna de una tabla (esto en realidad, es un requerimiento que no entiendo siquiera en AD_Fields; pero bueno, meter mano ahi es un poco mas complicado).

Estos AD_FieldExtends deberian una vez reflejados en instancias de FieldVO se deberian tratar casi de igual manera (por ej, tener callouts asociados, valores por defecto, logica de visiblidad, de solo lectura, etc; en el caso de botones tener procesos); esto es, gran parte de la logica que hace uso posterior de los objetos FieldVO (en particular, la que genera los controles de la GUI por cada uno de estos) este hecho debería ser transparente (en los puntos en que esto no sea asi, se agregar casos de excepción; digamos “if mField.isExtend hacer algo” si no, “hacer lo que siempre se hizo”; por ej, a nivel de persistencia, el código actual trata de manera especial a los campos “calculados”, esto es, los que surgen de “colmuna virtual”; simplemente los saltean al momento de hacer un sql insert o update).

Ok, como minimo, esto permitiria agregar facilmente botones (e.d procesos), sin necesidad ni de modificar la base de datos ni las las definiciónes de diccionario “base” (AD_Table, AD_Tab, AD_Field). En realidad, desde un punto de vista conceptual , los botones no tienen porque tener asociado un columna en una base de datos ya que no tienen “estado” (salvo los botones especiales de documentos, le veo poco sentido; el 99% de los botones actuales jamas afectan su valor ni hacen uso del mismo).
Posiblemente se complique un poco agregar “persistencia” a estos campos, pero tampoco lo veo muy complicado (mas que nada con teniendo una tabla intermedia AD_TabExtend que pueda, pero que NO requiera referenciar a una tabla en la base de datos).

Que opinan? Para mi esta bueno en el sentido de que puede permitir separar un poco las modificaciones especiales para un escenario particular y ademas simplificaria los upgrades (los campos ni las tablas base se modifican). Si se llegase a nivel de persistencia sobre las extensiones, incluso seria mucho mas simple de mantener y actualizar los requerimientos tipicos “quisiera que X entidad llevase información acerca de Y cuestion; y esto requiere se almacenen los datos A,B y C ” (los datos A,B C conceptualmete van a aparecer para el usuario “dentro” de la entidad X; fisicamente, pueden ir a parar a una tabla hecha de manera totalmente independiente; su reflejo en los metadatos tampoco implicarian modificar AD_Tab ni AD_Table).

Después si me hago un tiempo pongo una prueba de concepto utilizando solo codigo (e.d, no voy a hacer la tabla AD_FieldExtend, solo “simularla” desde codigo para algunas pestañas determinadas) para permitir agregar estos MField “extendidos”.

[Autor]

Entradas