Implementación de módulos externos

Question

¿Cuál es la mejor manera de implementar un sistema de módulo externo para una aplicación DELPHI?

Lo que necesito es muy básico realmente:

• La principal aplicación detecta si un módulo está presente y lo carga (tiempo de ejecución)
• módulos pueden almacenar forma
• módulos pueden almacenar DataModules
• Módulos pueden Almacenar código

Necesito el uso de los formularios de la tienda en otras formas, y solo como un standAlone

que usar algo como esto

 if Assigned(pNewClass) then begin 
      Application.CreateForm(pNewClass, _lFrm); 
      _lFrm.Hide; 
      _lFrm.BorderStyle := bsNone; 
      _lFrm.Parent := pBasePNL //(TPanel); 
      _lFrm.Align := alClient; 
     end; 

lo tanto, crear un TForm, pero colocarlo dentro de un TPanel.

En cuanto a los DataModules, usualmente almaceno ImageLists así que la idea es cambiar la aplicación ICO cambiando el módulo externo.

Entonces, ¿cuál es la mejor manera de lograr esto?

Miré BPL en tiempo de ejecución pero no parece entender cómo hacerlo. Gracias.

ACTUALIZACIÓN: .....................................

Después de leer algunas preguntas y respuestas relacionadas, creo que encontré mi respuesta y mi solución.

http://edn.embarcadero.com/article/27178

El artículo es algo viejo, pero increíblemente sencilla.

Bueno, la lógica es no sólo que no parecen llegar a Mostrar las formas 

sólo estoy probando el ejemplo 2

Se carga la BPL, pero no recibe el formulario:

AClass := GetClass('TForm2'); 

siempre Retrievex 'nil'

Pero la BPL, ya que registró:

RegisterClass(TForm2); 

¿Alguien puede ayudar con este.

Answer 1

¡Te hice una demostración, es muy fácil comenzar! Sin embargo ... Comenzó no está terminado.

Cada vez que comencé a usar complementos, más tarde me arrepentí. Sin embargo, como dices, quieres un sistema de complemento binario. Entonces los BPL son la solución correcta. David sugiere usar interfaces (con DLL simples en lugar del paquete de tiempo de ejecución completo BPL) y esto resolvería algunos de los problemas de inestabilidad de BPL comúnmente encontrados debido a no versionar sus clases, y por lo tanto sus dependencias de compatibilidad de aplicaciones y paquetes binarios. correctamente. Si no necesita compartir memoria y no necesita usar borlandmm.dll (administración de memoria compartida), una DLL directa con interfaces funcionará bien.

Si puede hacer todo lo que necesita hacer solo con scripts, y hacer su sistema de complementos con solo scripts, hágalo de esa manera. Si puede salirse con DLL, interfaces y sin compartir memoria, entonces use DLL simples. Si debe compartir memoria y tipos de clase, entonces sí, use BPL.

Tenga en cuenta que el uso de BPL (paquetes de tiempo de ejecución) tiene muchos efectos secundarios que podría no haber esperado. Las aplicaciones más grandes basadas en BPL en las que he trabajado han sido más desordenadas y menos estables que cualquier aplicación monolítica en la que haya trabajado. Parece que solo es posible pintar paquetes hasta que los pruebes, y luego me doy cuenta de que prefiero los monolitos.

Si usa los paquetes BPL correctamente y usted versiona sus complementos correctamente, todo está bien. BPLs son geniales. Pero en el mundo real, parece que el control de versiones y la compatibilidad e interoperabilidad de ABI y la estabilidad son muy importantes.

Actualización: Le hice una demostración que es here (plugin_r2.zip). Se realizó en Delphi XE, pero si está utilizando una versión anterior de Delphi, simplemente elimine los archivos .dproj y abra el archivo .dpr para la aplicación principal y el .dpk para el paquete.

Answer 2

Los paquetes son una solución fácil pero tienen un gran inconveniente. Usar paquetes obliga a los autores de los complementos a utilizar no solo Delphi, sino también la misma versión del compilador que tú.

Personalmente preferiría exponer la funcionalidad de la aplicación a través de una serie de interfaces. Esto permite el acceso desde otros idiomas además de Delphi.

Normalmente, el complemento se implementaría en una DLL y exportaría una función que la aplicación llamaría para pasar en la interfaz raíz que representa la aplicación. El complemento llamaría a los métodos de esa interfaz y establecería una interacción bidireccional.