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

[LoPiTaL]

Hola a todos!
Me asalta una nueva duda con la carga de paquetes en tiempo de ejecución. He seguido aténtamente este hilo http://www.clubdelphi.com/foros/showthread.php?t=68947
en el que Neftali explicaba de manera sublime los tipos de paquetes que podemos tener en nuestra aplicación.
Estoy desarrollando una aplicación en la que en un futuro esperamos hacerla crecer, por lo que me pareció interesante la carga dinámica de paquetes, así que me puse manos a la obra.
Tras darle varias vueltas, decidí por la opción (como dice el propio Neftali) más potente: BPLs cargados en runtime con la opción "Compile with Runtime Packages". Sencillamente funciona perfectamente.
El problema es que ahora me he dado cuenta que estos objetos (objetos maestros) que iré añadiendo a la aplicación, dependen también de otros objetos (objetos esclavos) que también me gustaría ir añadiéndolos dinámicamente.
Tengo la clase padre de ambos en un paquete en DesignTime, y los objetos maestros los puedo añadir fácilmente, derivando de su clase padre y registrándolos.
Pero éstos utilizan información sobre los objetos esclavos, la cual depende de qué tipo sea el esclavo, por lo que no puede estar en la clase padre de los objetos esclavos.
Por tanto, necesito tener información de ellos en DesignTime, por tanto se linkan estáticamente, por tanto, pierde la gracia hacer todo esto.

¿Me podríais indicar cómo puedo obtener información de estos objetos sin necesidad de tenerlos en DesignTime?
Yo estaba pensando en mantener records en DesignTime, y que al crear los objetos esclavos se le pase al constructor un puntero a dichos records.
El problema es que cualquier modificación en dicha estructura me obligaría a recompilar toda la aplicación...

Un saludo,
LoPiTaL

[ContraVeneno]

Me suena a que necesitas un BPL estático que te sirva de "puente" para tus cargas dinámicas.

Algo de esto se comenta en este enlace, podría servirte.

[LoPiTaL]

Gracias por la respuesta.

Lo que se comenta en ese hilo es lo que ya tengo:



Y eso funciona bien.
Ahora mi problema es que necesito que el Maestro hijo X acceda a información de los esclavos hijos Y, y dicha información, como es dependiente del tipo de esclavo que sea, no está en la clase padre.
Vamos quiero hacer esto otro:



Esa comunicación (marcada en rojo) es la que no sé cómo implementar sin caer en linkado estático, salvo añadiendo un BPL por cada esclavo hijo que únicamente contenga un pas con una estructura que sea la que el esclavo espera recibir, y a la que tendría acceso todo el mundo, por lo que este BPL sería estático, y un cambio en dicha estructura me obligaría a recompilar la aplicación.

¿Se os ocurre algo más? ¿Se me escapa algo?

Un saludo,
LoPiTaL

[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.