Usando varios patrones combinados

El siguiente es un caso de combinación de varios patrones para conseguir una presentación compleja, construída con gran economía de trabajo. El objetivo es obtener un editor que permita ver y procesar en una misma ventana, instancias de una relación padre/hijo (parent/child). De las distintas vías para lograr una visión integrada, y un trabajo cómodo para el usuario final, ésta es la que más ocupo.

El editor representa una relación entre una entidad padre (Owner) y una entidad hija (Owned), relación representada por un triple Owned by. Se usa un editor que hereda de Edit Detail para crear el panel básico. Esta primera herencia permite disponer de una región con una grilla de instancias de datos del padre (Datos generales de una cotización), y una región con detalles de una instancia relacionada con la grilla. A esta composición básica se le agrega una región adicional que agrega una segunda grilla con datos de detalle de una fila del padre (Detalles de una cotización), heredando de Grid2. Luego, se le agrega otra Región que hereda de Insert, para agregar filas a un detalle de cotización, relacionados con esta segunda grilla. Finalmente, se agrega funcionalidad para eliminar detalles, en la lista de botones de la segunda grilla. La figura 1 muestra las declaraciones que permiten componer el editor:

Figura 1

El mecanismo de herencia se completa con varios reemplazos: La primera herencia es implícita, al heredar la entidad Cotización (padre) de Edit Detail. Grid2 reemplaza la vista Grid2 de Uibasic con la vista Fetch de Detalle de cotización, e Insert reemplaza la vista Insert de Uibasic por la vista Update del Detalle de Cotización. Finalmente, para asegurar que en Grid2 se vean sólo los detalles de una fila del padre, se reemplaza la herencia del BlockFetch de Grid2, por el BlockFetchSet (que sólo trae las filas de un padre) heredado de Owned, y se agrega a Restrictor la vista Superkeys heredada de Owned por el Detalle, para restringir el Select (PositionGrid2) a las filas de un padre.

Una vez hecho esto, solo quedan dos pasos: Acomodar los controles en el panel de forma que sea usable para el usuario final, y modificar el diagrama de acción para unir las partes. La figura 2 muestra las regiones acondicionadas en su presentación definitiva:

Figura 2

Finalmente, se debe trabajar sobre el diagrama de acción para unir las partes: es importante tener en claro que con este mecanismo el trabajo es mínimo, ya que todos los servicios están implícitos en la herencia, a condición de que se haya trabajado definiendo apropiadamente el modelo: todas las validaciones básicas de cada atributo y de las relaciones entre las entidades (integridad referencial) son generadas por las metaoperaciones propias del Insert y el Edit Detail. Sólo pudiera ser necesario agregar validaciones con lógica más compleja, no representable por la definición de reglas de atributos o entidades. El mecanismo de creación de instancias está manejado en este caso por herencia adicional de Surrogate entity para el número de cotización y el detalle de ítems de la cotización. El mecanismo de presentación y recuperación requiere algunos pocos pasos de trabajo sobre el diagrama de acción. En este caso, es importante tener en cuenta de qué modo la herencia se combina en un diagrama de acción: La lógica propia de cada diagrama de acción se combina creando un nuevo diagrama integrado insertando la lógica de las partes en el orden secuencial de los triples en el modelo. Esto es válido para las áreas de inicialización, Manipulador de Eventos, y subrutinas. Un aspecto clave es el manejo de los puntos de edición. Siendo el requisito básico el que compartan un mismo tronco de herencia, los puntos de edición siguen el mismo patron, y se denominan de la misma forma en los casos en que cumplen la misma función, porque heredan esto de su ancestro. En estos casos, la lógica agregada a un mismo punto de edición se combinará en forma acumulativa, siguiendo el orden de los triples. De esta forma, no existe posibilidad de conflicto en el mecanismo de cada parte integrada. El requisito de compartir un mismo tronco de herencia es el elemento más básico que dificulta la integración de las clases OBASE con cualquier patrón posterior (Foundations).

En términos de esta aplicación, esto significa que en el editor construído, se creará el código basado en la estructura del diagrama de Edit Detail, y se le combinarán en los puntos de edición comunes, las secuencias de instrucciones de Grid2 primero, y de Input después. Así, el mecanismo de creación de instancias de Cotización lo hará el evento de Edit Detail (Process Update Request), y el de instancias de Cotización Detalle lo hará el evento Insert. Lo que falta para que el conjunto trabaje es muy poco:

La primera tarea se cumple insertando una llamada a Reload Grid2 al final de Load Detail del Edit Detail; la segunda se cumple agregando una llamada a Reload Grid2 al final de Insert. La tercera se resuelve creando un boton con un nuevo evento de borrado en GridButton2P, procesando la fila seleccionada con una variante de select Grid2. La figura 3 muestra la lógica insertada completa: lo indicado es suficiente para que el mecanismo trabaje: no mucho que hacer, como se ve.

Figura 3

La figura 3 muestra el editor en acción, creado como applet dentro de un browser:

Figura 4