La herencia es la propiedad que permite que un proyecto pueda hacer uso de los objetos de otro proyecto. Para ello debemos definir en la configuración del proyecto, en la pestaña correspondiente a la herencia, de qué proyectos queremos heredar sus objetos. Los proyectos de datos únicamente pueden heredar de otros proyectos de datos. Esto se debe a que los proyectos de datos han de ser independientes del interfaz de nuestras aplicaciones, e independientes del usuario por tanto, y funcionar de forma autónoma.
Los proyectos de aplicación heredan de los proyectos de datos sus objetos y sub objetos, permitiendo así que los objetos de la aplicación operen con las bases de datos que contienen los proyectos de datos. Además, los proyectos de aplicación pueden heredar de otros proyectos de aplicación. De esta forma podemos programar proyectos de aplicaciones haciendo uso tanto de los objetos de proyectos de datos como de los objetos de proyectos de aplicación.
Si un proyecto A hereda el proyecto B y el proyecto B hereda el proyecto C, el proyecto A también heredará el proyecto C sin necesidad de definir la relación de herencia entre ambos de forma explícita.
La herencia no es recíproca, no siendo posible establecer este tipo de relación entre dos proyectos.
Es posible heredar proyectos de otras soluciones de un mismo Velneo vServer. Solamente se podrán heredar proyectos de aquellas soluciones que hayan sido definidas como compartidas.
Cuando vayamos a diseñar una solución que implique diferentes tipos de herencia, debemos ser conscientes de que una instancia de un proyecto de aplicación no puede heredar dos instancias distintas de un mismo proyecto de datos.
Para verlo más claro, lo explicaré con un ejemplo. Partamos de esta estructura de herencias:
En la estructura anterior, el proyecto de aplicación A está heredando dos veces el proyecto de datos D, una a través de la herencia del proyecto de aplicación C y otra por la herencia del proyecto de Aplicación B.
Sería lo mismo que intentar asignar en la herencia de un proyecto de aplicación dos veces la herencia del mismo proyecto de datos, veremos que el sistema no deja hacerlo; de esta otra forma podemos hacerlo porque se está haciendo de forma indirecta.
Si tal y como tenemos definidas las herencias, instanciamos por un lado el proyecto C en una carpeta y por otro el proyecto B en otra carpeta, tendremos dos instancias distintas del proyecto de datos D.
Si ahora instanciamos el proyecto A , dado que por definición una instancia de aplicación no puede heredar más de una instancia de un mismo proyecto de datos, solamente heredará una de las instancias del proyecto de datos D, lo que provoca que, al ejecutar el proyecto A todo se ejecute todo contra la misma instancia de datos.
Como solución se podrían cambiar las herencias:
O bien hacer que B herede C, C herede B y A herede B:
O bien usar “arriba” dos proyectos de aplicación, en lugar de uno:
Es posible establecer herencia inversa entre dos proyectos. Cuando un proyecto A hereda un proyecto B, de forma automática, en el proyecto A podremos usar objetos del proyecto B, pero no al revés. Lo que la herencia inversa nos permite es hacer uso en el proyecto B de objetos del proyecto A. Esta herencia inversa no es automática sino programable.
La herencia inversa puede ser programada en formularios y en acciones.
Los pasos para programarla serán:
Crear en el proyecto B un objeto (formulario o acción) y activarle el estilo “Punto de inserción”.
En el proyecto A crear el objeto (formulario/acción) que se quiere usar en el proyecto B y crear dentro del mismo un sub-objeto inserción, en dicho sub-objeto se indicará el objeto del proyecto B donde se insertará el objeto actual.
Las acciones con herencia inversa solamente podrán ser usadas en menús y toolbars.
A nivel de base de datos una tabla padre conoce sus tablas de extensión y sabe como obtener la información de dichos registros. A nivel de interfaz existe una forma muy sencilla de incluir en el formulario de la tabla padre los subformularios específicos de cada tabla de extensión.
Vamos a verlo con un ejemplo práctico. Hemos creado en el proyecto Pedidos, que hereda un proyecto de una solución llamada vBase, las tablas de extensión CLIENTES, PROVEEDORES y AGENTES, todas ellas son extensión de la tabla de ENT (Entidades) de la solución vBase. Queremos incluir en el separador de pestañas un subformulario para cada tabla extendida, cada uno con los datos específicos de su tabla. Vamos a ver los pasos a seguir con la tabla CLIENTES.
Creamos el formulario con los datos específicos de los campos de la tabla extendida CLIENTES. También se incluye en ese formulario un separador de pestañas con el histórico de pedidos.
Una vez creada ese formulario lo insertamos en el separador de pestañas del formulario de la tabla padre ENT (Entidades) mediante un punto de inserción. A esto es a lo que denominamos herencia inversa porque el formulario de Entidades está en un proyecto que no conoce a Pedidos, y sin embargo podemos conseguir que en ejecución ese formulario incluya un subformulario de un proyecto que se lo ha insertado en uno punto de inserción.
Como podemos ver en la imagen anterior, se ha añadido una nueva propiedad al subobjeto inserción para la aplicación de herencia inversa. Se trata de la propiedad Tablas de extensión. Cuando se da esa circunstancia Velneo nos permite seleccionar si en la pestaña correspondiente a este subformulario se mostrará el botón de alta (si no existe la ficha de extensión) y/o el botón de baja (si ya existe la ficha de extensión). Esto nos permite configurar que permisos le otorgamos al usuario para crear o eliminar manualmente registros de extensión. Incluso podríamos añadir dos veces el mismo subformulario con diferente configuración en la propiedad Tablas de extensión y con condición de visible ajustada para el perfil de usuario correspondiente.
Aplicando el mismo criterio a los formularios de las tablas de extensión de PROVEEDORES y AGENTES, el formulario de ENTIDADES del proyecto de aplicación de la solución vBase podría mostrar el siguiente aspecto.
Como podemos apreciar en el formulario de ENTIDADES existen 3 pestañas correspondientes a las tablas de extensión añadidas por herencia inversa que además muestran un botón con un más o un menos en función de si existe o no existe el registro de extensión.
Por defecto una entidad sólo tendría sus datos básicos, si una entidad pasa a ser cliente el usuario podrá pulsar en el botón más de la pestaña y añadir los datos específicos como cliente, si posteriormente esa entidad también es proveedor, el usuario procedería de igual forma y lo mismo pasaría con las entidades que correspondan a agentes comerciales.
Los registros de extensión también pueden crearse de forma programada, simplemente creando el registro en la tabla correspondiente y asignándole al campo ID el mismo que tiene la tabla padre.
Si nos fijamos en el formulario anterior de ENTIDADES podemos que en la parte inferior de botones existe uno con el texto Extensiones. Este botón al pulsarlo mostrará la lista de extensiones que han sido declaradas mediante puntos de inserción en el formulario. La imagen siguiente muestra como se visualizan las opciones al pulsar el botón.
Como vemos se muestran activas las opciones para las que todavía no está creada la ficha de extensión. Para programar este botón tan sólo es necesario añadir el botón en el formulario y asignarle uno de los siguientes comandos de botón:
Alta de ficha en tabla de extensión (es la opción que tiene por defecto el botón de la pestaña).
Alta controlada de ficha en tabla de extensión (que solicita confirmación antes de dar el alta).
Como vemos no sólo resulta muy sencillo crear las tablas de extensión, sino que además es igual de fácil programar nuestro interfaz para incluir en el mismo formulario información de la tabla padre y de sus tablas de extensión.
