Cómo conseguir paquetes dinámicos y no necesitarlos en DesignTime

[ContraVeneno]

Desconozco la forma en que podrías tener "comunicación directa" entre dos BPL dinámicos. Lo que yo hago es hacer la comunicación a traves de un BPL Base. Tu podrías utilizar tu módulo maestro o esclavo para tener esa comunicación, pero sería indirecta.

Por eso yo hacía la mención de un BPL "Puente" que te sirva de camino.

[Neftali [Germán.Estévez]]

Siguiendo con lo que comenta Contraveneno, entiendo que hay dos formas de acceder a información de otros packages.

El primer problema es saber a qué te refieres con "comunicación"; No es lo mismo acceder a datos, crear objetos definidos en otro paquete, acceder a métodos de clase,...

(1) La forma directa pueder ser utilizando RTTI. Si tu aplicación está compilada con Runtime Packages, como debe ser, puedes utilizar técnicas de RTTI para acceder a determinados datos.

(2) La forma "indirecta" y es la que también uso yo, es la que ha comentado contraveneno. Utilizar una estructura en el package Base o en el programa principal para almacenar cosas que serán accesible por todos los packages.

Por ejemplo, en mi caso, tengo una "lista de Definiciones" en el package Base. Cada package que cargo añade a esa lista (accesible por todos los packages) su objeto definición (que contiene todo lo que los demás necesitan saber de ese package; constructores de clase, definiciones,...)

Una vez cargados los packages, en esa lista están los "objetos definición" de los packages cargados y los que no se han cargado no han añadido su "objeto definición".

[roman]

El problema, hasta donde veo, es que sus clases "maestras" hacen uso de clases "esclavas" específicas por lo que el paquete base tendría que incluir a todas ellas, aún las que no existan en el presente.

Obviamente es poco lo que se puede decir sin mayores datos, pero podría tratarse de un diseño de clases no del todo correcto. Las clases "esclavas" probablemente deberían de poderse acceder de manera genérica y dejar al polimorfismo la distinción de comportamientos.

// Saludos

[LoPiTaL]

Gracias a todos por las respuestas.

Neftali:

El primer problema es saber a qué te refieres con "comunicación"

Con esto me refiero a que:
- El maestro deberá inicializar con unos determinados valores a los esclavos.
- Deberá leer sus datos.
- Los esclavos no necesitan saber nada de los maestros salvo lo que está en el paquete principal.

La forma directa pueder ser utilizando RTTI

No me gustaría usar RTTI, por aquello que hace la app lenta.

Utilizar una estructura en el package Base

Eso es lo que comentaba que es lo único que se me había ocurrido. Creas un record de esta estructura, lo inicializas y se lo pasas al constructor del esclavo y ya se apañará.
Esta es la solución que por ahora más me gusta...
Su única pega es que si en versiones posteriores introduces cambios en esta estructura, debería actualizar toda la app y no sólo el package.

Cada package que cargo añade a esa lista (accesible por todos los packages) su objeto definición

¿Puedes explicar un poco más esto? ¿A qué te refieres con "objeto definición"? ¿Por ejemplo a un array de strings del tipo 'NombreVar=Valor'? Si es así, tal vez podría utilizar estructuras tipo XML para conocer el estado de los esclavos o inicializarlos... (se me acaba de ocurrir, mañana lo estudiaré más tranquilamente esto)

Román:

El problema, hasta donde veo, es que sus clases "maestras" hacen uso de clases "esclavas" específicas por lo que el paquete base tendría que incluir a todas ellas

Sí, exactamente ese es el problema que tengo. Las clases esclavas comparten métodos genéricos a todas ellas, por tanto sí puedo hacer herencia / polimorfismo. Pero hay determinadas propiedades que son exclusivas de determinados esclavos. Esto es lo que no consigo resolver.

podría tratarse de un diseño de clases no del todo correcto

No descarto que sea este el problema, pero como he dicho antes, los esclavos comparten métodos y propiedades accesibles a través del esclavo padre, pero hay cosas que dependen de lo que el esclavo haga.


Después de todo esto, me está pareciendo cada vez más simple dejar los esclavos que se linken de forma estática en todos los packages de los maestros que los necesiten, y cuando haga una actualización en cualquier package de algún esclavo, actualizar también todos los packages de maestros que dependan de él...

Gracias por las respuestas,
Un saludo,
LoPiTaL

[Neftali [Germán.Estévez]]

Empezado por LoPiTaL

No me gustaría usar RTTI, por aquello que hace la app lenta.

Bueno, personalmente no tengo constancia de que RTTI haga más lenta la aplicación; Lo he leído en algun sitio más, pero no se si realmente es cierto y si lo es, habría que saber cómo cuantificamos ese "mas lento".
En todo caso dependerá de las operaciones que hagas utilizando RTTI; De cuales y de cuantas.

Empezado por LoPiTaL

¿Puedes explicar un poco más esto? ¿A qué te refieres con "objeto definición"?
¿Por ejemplo a un array de strings del tipo 'NombreVar=Valor'?
Si es así, tal vez podría utilizar estructuras tipo XML para conocer el estado de los esclavos o inicializarlos... (se me acaba de ocurrir, mañana lo estudiaré más tranquilamente esto)

Le he llamado "Objeto definición", porque en mi caso es una clase que contiene varias cosas.
En mis packages dinámicos existen clases (en cada package N clases); Cuando se carga un package se añade a la lista, un objeto por cada una de las clases que hay en ese package.
¿Qué contiene ese objeto definición? En mi caso ese objeto contiene un Identificador, algunas propiedades que se necesitan conocer de esa clase, apuntadores a constructores (Edit, Browse,...), información de inicialización, el package al que pertenece,...

Cuando acaba la carga de la aplicación, esa lista de definiciones, contiene 1 objeto (con toda la información anterior) de cada clase que se ha cargado. Viene a ser como un "diccionario de clases" (en realidad lo es) y me sirve como complemento a la RTTI.