V7 – Cajas y relación de conocimiento

En V7 aparece el revolucionario concepto de caja que no existía hasta ahora en nuestra herramienta de programación. En este documento vamos a analizar el aspecto práctico de las cajas y las relaciones de conocimiento o herencia que se establecen entre ellas.

Cajas
Comenzaremos por ver el concepto de caja. Es probablemente la novedad más importante a nivel de análisis y programación de V7. Hasta ahora nuestros proyectos eran monolíticos, es decir, se programaba sobre un único fichero o en caso de programar en equipo al final era preciso unir en un sólo mapa todo el código generado. Existen 2 tipos de cajas en V7, de datos y de objetos.

Cajas de datos
Podemos asociar el concepto de caja de datos a lo que hasta ahora era la parte izquierda del Edmap:
Tablas.
Tablas estáticas.
Variables globales.

Cajas de objetos
La caja de objetos equivale a la parte derecha del Edmap:
Carpetas.
Objetos visuales

Antes de V7, después de V7
Como podemos observar hasta antes de la V7 nuestros desarrollos equivalían a utilizar el nuevo sistema de cajas con:
Una sola caja de datos y
Una sola caja de objetos.
Sin embargo, apartir de V7 podremos tener tantas cajas de datos y de objetos como queramos, el servidor de edición se encargará de gestionar las cajas y la edición de las mismas controlando los bloqueos.

Las cajas no son entidades aisladas, entre ellas se pueden establecer relaciones de conocimiento que permiten a la caja que recibe el conocimiento de otra el uso de todos sus objetos. De esta forma cuando una caja A conoce todos los objetos de una caja B, desde la caja A se podrán usar todos los objetos de la caja B como si estuviesen declarados dentro de la caja A, con la ventaja de que en realidad estos objetos sólo existen en la caja B y, de esta forma el mantenimiento de los mismos será mucho más sencillo a la vez que se permite que una caja pueda ser conocida por muchas cajas que reutilizan su código.

Con la herencia y el conocimiento todo encaja
El mayor avance que llegará con las cajas es la herencia, pero en este documento vamos a centrarnos en las relaciones de conocimiento entre cajas y la reutilización de código que permite esta característica.

En el gráfico se observa como la caja de datos vGestion conoce la caja de datos vBase por lo que las tablas de vGestion pueden tener enlaces directos a las tablas de vBase, por ejemplo desde la tabla Facturas de vGestion se puede añadir un campo puntero a la tabla de Entidades de vBase, pese a que físicamente la tabla Entidades no existe en vGestion y sólo existe en vBase.

Uno de los problemas que se podrían plantear con el uso de cajas es que, siguiendo con el ejemplo anterior, la tabla de Entidades de vBase no tiene conocimiento de que es usada en vGestion y por lo tanto no podría crearse una relacion de histórico con la tabla de Facturas de vGestion, sin embargo el servidor de edición mediante la técnica de conocimiento inverso es capaz de analizar los enlaces entre tablas de diferentes cajas y permite automatizar las relaciones a histórico. Es importante tener claro que:
Una caja de datos podrá conocer a otras cajas de datos pero no cajas de objetos.
Una caja de objetos podrá conocer a otras cajas tanto de datos como de objetos.

Trabajando en equipo gracias al gestor de cajas
Las cajas nos van a permitir una organización de nuestros proyectos adecuada al trabajo en equipo ya que cada programador podrá estar editando una caja diferente sin que existan conflictos debido a que los bloqueos son gestionados por el servidor de edición.

En el gráfico podemos observar como la caja de objetos vCompras recibe el conocimiento de la caja de datos vGestion y de la caja de objetos vBase. Esto permite que desde cualquier objeto de vCompras se use de forma directa cualquier tabla, tabla estática o variable global declarada en el DataBox vGestion y también cualquier objeto visual existente en la ObjectBox vBase.

Será habitual que en nuestros desarrollos nos encontremos con múltiples cajas y que entre ellas se definan múltiples relaciones de conocimiento. Esto que aparentemente puede ser sinónimo de complejidad es sencillo de comprender si vemos al servidor de edición y a su gestor de cajas como si de un mapa antiguo se tratase, ya que el gestor conoce todas las cajas y los objetos contenidos en las mismas, por este motivo cuando declaramos que una caja conoce a otra simplemente estamos activando la posibilidad de que una caja use los objetos de la otra, es lo mismo que ocurre ahora cuando declaramos una relación de histórico en una tabla, en esa declaración no se realiza nada físico, simplemente estamos dando a conocer como se relacionan dos tablas y es a través del uso de esta relación cuando se puede navegar a través de la información, el conocimiento de las cajas es similar, se trata de establecer la relación de uso sin que esto suponga ninguna acción o limitación.

Conocimiento bidireccional con identificadores únicos
Una caja A puede conocer a otra caja B y a su vez la caja B podrá conocer la caja A. Un ejemplo práctico lo encontramos en un programa de gestión, tal y como vemos en el gráfico el uso del conocimiento bidireccional nos permite que desde un pedido de compras podamos mostrar información del pedido de ventas, incluso utilizar los formularios para editar la información y desde el pedido de ventas hacer lo mismo con el documento de compras, todo ello teniendo los objetos visuales definidos una única vez, en su caja correspondiente.

Todo esto es posible debido a que el gestor de cajas conoce todas las cajas con un identificador único y por lo tanto los objetos contenidos dentro de una caja vienen definitidos por el identificador de la caja más el identificador del objeto lo que garantiza que dos cajas distintas pueden tener un objeto con el mismo identificador sin que esto produzca ningún conflicto ya que cada objeto es distinto para el gestor.

Por ejemplo, en las cajas de vCompras y vVentas podríamos tener declarado un objeto formulario para el alta de pedidos y aunque dentro de cada caja el objeto aparentemente se llama igual, a nivel del gestor de cajas el nombre de cada formulario sería:

• OBJECTBOX-COMPRAS.PEDIDO-ALTA
• OBJECTBOX-VENTAS.PEDIDO-ALTA

Etiquetas: cajas de datos, cajas de objetos, conocimiento, herencia, Velneo V7