Discussion :

[st20085]

Bonjour

Je développe une application (JAVA, SWING, ...) avec IHM (arbre, édition de données) sur des données techniques qui permettent de générer un programme en code C
ainsi que des documents (pour le moment au format Excel).
Dans le cadre de "simplification" (avant que notre application devienne trop énorme), nous souhaitons
séparer dans des jars différents, la partie kernel (données) et IHM de la partie génération de code et document.
Je voudrais avoir un jar principal ainsi que des "sous-jar" : un pour la génération de code et un autre pour la génération des documents.
Je cherche donc un cours/tutorial/aide sur la création d'un système de plugin (de manière générale) pour mon application qui permettrait de rajouter
des menus/actions/buttons/traitements ainsi que de personnaliser l'édition des données.

Merci

[Patriarch24]

Ici par exemple...

[Baptiste Wicht]

Bonjour

Je développe une application (JAVA, SWING, ...) avec IHM (arbre, édition de données) sur des données techniques qui permettent de générer un programme en code C
ainsi que des documents (pour le moment au format Excel).
Dans le cadre de "simplification" (avant que notre application devienne trop énorme), nous souhaitons
séparer dans des jars différents, la partie kernel (données) et IHM de la partie génération de code et document.
Je voudrais avoir un jar principal ainsi que des "sous-jar" : un pour la génération de code et un autre pour la génération des documents.
Je cherche donc un cours/tutorial/aide sur la création d'un système de plugin (de manière générale) pour mon application qui permettrait de rajouter
des menus/actions/buttons/traitements ainsi que de personnaliser l'édition des données.

Merci

L'architecture que tu défini ici, ce n'est pas vraiment un système de plugin... Il suffit que tu sépares les classes dans des jars différents et que le jar principal importe les jars secondaires, c'est tout.

Un système de plugin, c'est un système modulaire auquel tu peut ajouter et supprimmer des modules.

[st20085]

Tout d'abord merci pour les réponses

>wichtounet: Justement, je ne veux pas importer mes jars secondaires dans mon jar principal, un peu comme la plateforme eclipse qui permet de rajouter des plugins alors qu'eclipse ne connait pas le contenu du plugin

[Baptiste Wicht]

Tout d'abord merci pour les réponses

>wichtounet: Justement, je ne veux pas importer mes jars secondaires dans mon jar principal, un peu comme la plateforme eclipse qui permet de rajouter des plugins alors qu'eclipse ne connait pas le contenu du plugin

Ah ok, je t'avais mal compris, j'ai cru que tu voulais juste séparer plusieurs parties de ton programme.

Alors le lien de Patriarch devrait te convenir

[st20085]

>Alors le lien de Patriarch devrait te convenir
Je viens de le lire, et je m'apercois que mon collègue, qui avait commencé à développer le plugin, à complètement suivi ce tutorial (quasiment mot à mot : trop drole)

Néanmoins, je me demandais si c'était la meilleure solution, et je pensais qu'au lieu que la classe qui implémente les méthodes du plugin pour renvoyer des objets typiques pour mon application, il ne serait pas mieux de renseigner au plugin une instance de mon application, le plugin pourrait récupérer, par exemple, la barre de menu pour rajouter ces propres menus ou la barre d'outils pour rajouter des boutons, et ainsi de suite
qu'en pensez-vous?

[st20085]

Personne pour me donner son opinion?

[cdelhorbe]

Néanmoins, je me demandais si c'était la meilleure solution, et je pensais qu'au lieu que la classe qui implémente les méthodes du plugin pour renvoyer des objets typiques pour mon application, il ne serait pas mieux de renseigner au plugin une instance de mon application, le plugin pourrait récupérer, par exemple, la barre de menu pour rajouter ces propres menus ou la barre d'outils pour rajouter des boutons, et ainsi de suite
qu'en pensez-vous?

Je pense que tu prendrais le problème à l'envers, et te priverais d'une certaine souplesse dans la gestion des actions. Par exemple, peut etre que qd tu as trop d'icone sur ta barre d'outils, certains vont etre masqués, avec des chevrons pour les afficher. ceci est du ressort de l'application principale , qui aura donc besoin de pouvoir récupérer toutes les actions des plugins pour prendre ces décisions. Autre cas de figure : tu développes ta barre d'outil classique, et dans une V2, tu en fais un barre ala office 2007 (ribbons, un truc assez différent dans le rendu), l'interface de ta barre de menu change. ça sera plus facile de juste modifier le code de la barre de menu qui récupèrera toujours les actions des plugins de la meme façon, plutot que de modifier le code dans chaque plug in.
En plus, si tu suis ce principe pour tout ton développement et que tes plugins ne dépendent pas de ton application principale, ils seront plus facilement testables indépendamment, et pourront meme etre réutilisés dans d'autres contexte (on ne sait jamais).

C'est mon avis, ça n'engage que moi