Forum Programmation.autre développement d'un système de plugin

Posté par  .
Étiquettes : aucune
0
13
déc.
2004
Bonjour,

Je souhaiterais savoir comment implémenter un système de plugin pour un logiciel. Cela repose-t-il sur un design pattern particulier, quelles sont les techniques, les méthodes les plus récentes, les plus générales...


Je recherche comment intégrer la fonctionnalité plugin dans un logiciel.

  • # la base

    Posté par  (site web personnel) . Évalué à 2.

    Si tu te bases sur un langage objet qui possède des fonctionnalités d'introspection (en gros la possibilité de demander des infos sur le programme en soit), c'est très facile : un plugin doit implémenter une interface bien précise qui répond à certaines fonctionnalités qu'il doit remplir, puis tu décide d'un moyen d'encapsulation : par exemple un jar en Java, et hop ensuite tu écris un morceau de code qui cherche dans un dossier "addons" ces plugins et tu les charge dynamiquement avec les méthodes qui vont bien.
    Bon je suis pas sûr que je sois bien clair, mais d'un point de vue technique c'est extrêmement simple.
    Après ça se complique si tu veux contraindre tes plugins, les isoler, etc.

    Voilà par exemple la liste des méthodes que tu pourrais trouver dans une interface définissant un plugin d'export de données (très sommaire) :

    interface MyApplication.MyExportInterface
    getName() : string
    getVersion() : string
    SaveData(datas : MyApplication.MyPersistentData, URL : string)
    getSupportedFormat() : StringCollection

    Ensuite l'algo général de chargement des plugins au lancement de ton application (toujours dans un pseudo code) :

    string location = "~/.MyApplication/addons/"
    foreach bin in location
    if bin implements MyExportInterface
    mesplugins.add(bin.createInstance)
    endif
    endforeach

    Libre à toi de remplacer le getSupportedFormat et le SaveData par ce que tu veux offrir comme possibilité aux plugins.

    • [^] # Re: la base

      Posté par  . Évalué à 1.

      ok, mais on dirait que ce que tu me proposes c'est de faire une interface pour un type de plugin particulier (dans ton cas seulement faire de l'export de données).

      Mais si je veux créer une interface qui permette au créateur de plugin de faire ce qu'il veut : export de données mais aussi ajout d'un item dans les menus proposés par l'appli et réaliser une action sur l'appli, afficher des fenetres de dialogue en plus. J'aimerais pouvoir réaliser une integration parfaite entre le logiciel (qui sera une base à plugin, en fait une sorte de gestionnaire de plugin) et ensuite d'en faire le logiciel que je veux uniquement à l'aide de plugin.

      Est-ce que ce serait possible ? par exemple en créant une classe abstraite qui permettrait de donner un accés à tous les éléments du programme et aux autres plugin et à leurs éléments.

      Ou alors est-ce qu'il faut faire une interface simple qui contiendrait une méthode action() qui serait implémenté dans un plugin qui réaliserait une action trés simple et ce serait grâce à la combinaison d'un certain nombre de plugin qu'on arriverait à des action complexe ?

      Un truc à l'image de eclipse par exemple (comment ça marche pour lui)?

      • [^] # Re: la base

        Posté par  (site web personnel) . Évalué à 2.

        Effectivement j'ai contraint le plugin avec des méthodes à implémentées par mon application "sait" qu'elle a besoin d'un plugin, mais pas lequel.
        Si tu veux faire un plugin sans aucune contrainte qui fait un peu ce qu'il veut, ben supprime les méthodes spécifiques (SaveData et GetSupportedData), après de toute façon le plugin aura été compilé avec une référence à ton appli, et lors de son chargement (quand tu créera une instance) il peut très bien aller taper dans tes objets, s'incruster dans tes menus, etc, à partir du moment où ils sont accessible quelquepart (dans une classe en tant que champs statiques par exemple, ou plus propre à travers un singleton).
        Après il faut que tu documentes bien ton appli on précisant bien ce qui pourrait être utilisé par les plugins.

        • [^] # Re: la base

          Posté par  . Évalué à 1.

          D'accord je commence à percevoir le système.
          Sais-tu si il existe des ressources sur le net ou dans des livres pour créer des plugins ?

          • [^] # Re: la base

            Posté par  . Évalué à 1.

            Bon, ok, je ne suis pas très calé sur le sujet, mais j'ai peut-être une piste intéressante à te proposer : les sources de kde.
            Ou plus particulièrement ce que tu trouveras dans le répertoire konq-plugins si tu récupères le tarbal de kdeaddons. La plupart sont des plugins qui remplissent le menu outils de konqueror.
            En espérant que ça t'aidera dans ta démarche.

          • [^] # Re: la base

            Posté par  (site web personnel) . Évalué à 2.

            SI tu veux tu peux jeter un coup d'oeil sur cette doc du projet SharpDevelop qui a justement pour but d'expliquer une architecture d'add-on, relativement simple et dans un langage objet :
            http://www.sharpdevelop.com/TechNotes/ProgramArchitecture.pdf(...)

      • [^] # Re: la base

        Posté par  (site web personnel) . Évalué à 2.

        ok, mais on dirait que ce que tu me proposes c'est de faire une interface pour un type de plugin particulier (dans ton cas seulement faire de l'export de données).

        un plug-in est toujours "particulier" ne serait ce qu'au logiciel qui l'appelle.
        Par exemple, pour des logiciels de player mp3, tu as 3 types de plug-in (output,input et visualisation) et tu peux pas "interchanger" les 3.

        Un plug-in "général" pourrait n'implémenter que la méthode "run" ou quelque chose de similaire. Mais il serait intelligent de créer un "protocole" pour être sur que c'est bien un plug-in que tu essayes d'executer. Donc, le logiciel qui va executer le plug-in doit vérifier qu'il possede bien la méthode nécessaire "run" et si celle ci doit avoir des parametres, bien vérifier que ceux ci sont correctement passé au plug-in.

        Axel

      • [^] # Re: la base

        Posté par  (site web personnel) . Évalué à 2.

        Si je peux me permettre, un plugin qui peut faire ce qu'il veut c'est une très mauvaise idée. En effet, si tu ne figes pas une interface pour tes plugins, tu devras figer toute l'API de ton logiciel car un plugin pourra avoir surchargé une des méthodes que tu veux changer.

        Tu dois donc obligatoirement classifier tes plugins. Par exemple si on prends l'exemple de noAtun, il y a des plugin "playlist", "player", "effet visuel",.... Chacun implémente une interface qui a été figée afin de conserver une compatibilité optimum avec les versions futures.

        Si je prend l'exemple de konq-rellinks ( http://shift.freezope.org/konq_rellinks(...) ) sur lequel je travaille, on a tenté de rajouter une barre de menu supplémentaire à Konqueror pour gérer les "links". C'est le premier add-on de Konqueror à le faire. Eh bien le problème c'est que la gestion des toolbars de Konqueror a dernièrement été changée et maintenant ça bug à mort. Bref si l'interface de communication change c'est la merde.
        D'ailleurs on cherche des personnes pour nous aider pour cet add-on. Je n'ai en effet pas le temps et les connaissances pour maintenir ce projet. Il va être retiré de KDE si pas de mainteneur.

        Donc, un conseil, réfléchit bien aux interfaces de tes plugins et limite leur environnement sur lequel ils peuvent intervenir.

        L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

        • [^] # Re: la base

          Posté par  (site web personnel) . Évalué à 3.

          Sans parler du fait qu'il faille figer l'appli, une ouverture totale laisse complètement tomber la sécurité : le plugin peut fait n'importe quoi, et de préférence des conneries : faire planter un autre plugin, "virusser" l'application, etc.

          • [^] # Re: la base

            Posté par  . Évalué à 1.

            il me faut donc développer un "coeur" pour mon appli de telle sorte que je puisse le faire évoluer sans que cela ait pour conséquence de perturber ni les plugin ni la sécurité de mon appli. Et prévoir un certain nombre de catégories de plugin "généraux-spécialisés".

            Ca donnerait un truc du genre le coeur est une sorte de multiconteneur (conteneur de menu, conteneur d'éditeur,...) et des plugin associés à chacun de ces conteneurs ou à un certain nombre de conteneurs.

            Par exemple, l'application peut contenir une zone de texte éditable et proposer un plugin "modificateur de zone de texte" qui, une fois implémenté, permettrait de donner accés au contenu de l'editeur ce qui permettrait de développer un plugin pour la représentation en mémoire du texte qu'il contient, un plugin pour la coloration syntaxique, un plugin pour la complétion automatique, un plugin pour l'indentation automatique ou encore pour le style de codage, etc.

  • # Eclipse

    Posté par  . Évalué à 0.

    Salut,

    eclipse propose un systeme de plugins et d'extension pas mal, qui est plus est c'est bien documenté.

    un article
    http://www-106.ibm.com/developerworks/opensource/library/os-ecplug/(...)

    avec des liens en bas de la page pour approfondir

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.