[Indications][Architecture] Un problème de plug in

**Giovanny Temgoua** · 20/03/2007, 10h42

Bonjour,

Je suis entrain de mettre sur pied un portail et je me bloque un peu sur comment faire l'architecture de mon application.

Nous aimerions pouvoir avoir un système de plug in dans le portail de sorte que cà nous permettre de développer des modules indépendamment. Pour une application windows, c'est pas vraiment compliqué mais là je dois avouer que je ne vois pas trop comment appliqué la même chose dans le cas d'une application Web...

J'explique sommairement ce qu'on attend du système de plug in.

Chaque module (dénommé service) offre un ensemble d'opérations et des droits sur les objets qu'il manipule. Par exemple, si on a un module des gestions des utilisateurs, on pourra
- ajouter
- éditer
- supprimer un utilisateur.

Une fois le service recensé (donc le plug in installé - il faudra donc réaliser un installeur de plug in

), il faudra que les droits qu'il mettent à disposition soient recensés dans l'ensemble des droits du système. De sorte que le système puisse ensuite décider ou non d'attribuer un droit exposé par un service à un autre service.

Exemple.

On a les services A et B.
A introduit les droits E1, A1 sur certains objets.
B introduit les droits E2, A2 sur certains objets.
(E = Edition, A = ajout)

Pratiquement, dans l'interface du super admin, on devrait pouvoir faire E1 et A1 puisque l'admin aura tous les droits sur tous les services recensés. Maintenant, on aimerait que l'admin puisse attribuer le droit E1 à B !

J'ai cherché des tutos afin de voir comment construire des applications Web avec un système de plug in mais je n'ai pas trouvé quelque chose qui puisse réellement m'aider. Peut être ai-je mal cherché ?

Toute indication/conseil serait la bienvenue.

Merci.

PS : il y'a des portails Web qui ont un système quasi identique à ce que je viens de décrire (tel que joomla : www.joomla.org , écrit en PHP). Je pense qu'il y'a DotnetNuke qui doit avoir aussi un système de plug in (je ne sais pas, je suppose) mais le temps d'étudier leur code pour comprendre l'idée générale me semble plus pénible. (j'ai téléchargé le code de la dernière version, je l'ai sous le code au cas où ...)

**Pierre Henri Kuate** · 21/03/2007, 17h54

Je ne connais pas DotNetNuke en profondeur, et encore moins Joomla mais je ne pense pas que leurs "plug-ins" fonctionnent comme ça...

Est-ce que tu pourrais expliquer le problème qui t'a poussé à vouloir ce type d'architecture ? Il est fort probable qu'il soit solvable sans passé par ça (sinon, ça aidera à comprendre cette architecture)

"L'architecture la plus simple est toujours la meilleure"

**Ditch** · 21/03/2007, 18h03

Le problème est que souvent il est nécessaire de faire un "noyau" ou "moteur" ou peu importe le terme et d'ajouter des composants sans toucher au code de ce moteur.

Niveau pattern il existe un à ce sujet mais je ne connais plus le nom par coeur.

**Giovanny Temgoua** · 22/03/2007, 18h32

Bonsoir,

Envoyé par Ditch

Le problème est que souvent il est nécessaire de faire un "noyau" ou "moteur" ou peu importe le terme et d'ajouter des composants sans toucher au code de ce moteur.

C'est effectivement ce que je veux faire

Envoyé par KPixel

Est-ce que tu pourrais expliquer le problème qui t'a poussé à vouloir ce type d'architecture ? Il est fort probable qu'il soit solvable sans passé par ça (sinon, ça aidera à comprendre cette architecture)

Alors,

Tout d'abord, le besoin d'avoir ce noyau central que je n'aurai pas à modifier chaque fois que je vais ajouter un nouveau module à l'application. Sauf bien sûr en cas de MAJ "critique".
Maintenant, je souhaiterai pouvoir faire des modules (ou dans le meilleur des cas, permettre à des tierces personnes de pouvoir en faire) de telle sorte que :
- le module soit automatiquement recensé parmi les modules installés
- que les droits d'accès au module soient également recensés.

Je vais prendre un exemple de ce que je veux faire.

J'ai l'application centrale, un site par exemple. On souhaite pouvoir ajouter différents modules donc par exemple le module de bannières. Sur une bannière, on peut effectuer les opérations classiques d'ajout, d'édition, et de suppression d'une bannière.

Le module doit fournir toute la logique nécessaire pour fonctionner, en utilisant éventuellement des éléments du noyau central (par exemple des tables de la base de données centrale). Le module pourra également créer ses tables à lui pour stocker les infos qui lui sont propres. Ces tables sont créees à l'installation du module et détruites à sa désinstallation.

Donc, le module apporte en gros
- de nouvelles tables
- des droits sur ces tables via des pages

Maintenant, ce que je veux faire c'est de recenser les droits sur la gestion des bannières. L'admin d'office en installant le module aura tous les droits qu'il propose. Il est maintenant question que l'admin puisse octroyer un sous-ensemble de ces droits à un autre utilisateur (par exemple, octroyer juste l'ajout et l'édition à un utilisateur donné).

De plus, le module pourra avoir des relations de dépendance avec d'autres modules. De sorte à ce que les infos en sortie d'un module (une liste de quelque chose) puisse être utilisés en entrée d'un autre module.

Voilà, en espérant avoir donné plus de détail

Merci !

**Pierre Henri Kuate** · 22/03/2007, 22h33

Ceci ne réponds pas à ma question.

Là, tu viens de détailler ta "solution". Ce que je veux, c'est les détails sur le problème.

Cette solution est, à mon avis, très complexe donc je me demande si elle vaut vraiment la peine.

Note: Les "plug-ins" marchent bien pour des fonctionnalités très specifiques; dans ce cas, il s'agit de "plug-ins" contenant des pages web, tables, et tout ce qu'il y'a au milieu (entités, logique, code d'acces de donnée, etc.)... Et si tu ajoute la gestion de dépendences...

**Ditch** · 22/03/2007, 22h44

Je ne vois pas ce qu'il peut te dire de plus. C'est un problème courant (même si la solution n'est pas triviale). C'est un quelque sorte se créer un framework sf qu'il intègre la partie visuelle.

L'extensibilité des applications est quelque chose qui est de plus en plus nécessaire. Parfois pour des raisons de licence (on ne vend qu'une partie), parfois parce que ce sera d'autres personnes qui vont développer les composants et qu'on ne peut donner le code source du hôte.

**Ditch** · 24/03/2007, 15h54

En tout cas, pour ma part, je partirais sur une solution basée sur un chargement de dll à la volée. Dans ces dll les composants doivent implémenter une interface que tu définis dans un projet quelconque.

Tous les composants doivent implémenter cette interface sans quoi c'est niet. Cela ne devrait pas poser trop de problème. J'avais fait ce système sans le chargement dynamique et ca marchait nickel.

Tu devras cependant faire un gestionnaire de plugins pour persister les informations sur ce que tu veux ou ne veux pas charger.

Que penses-tu de cela?

**Giovanny Temgoua** · 24/03/2007, 16h37

Envoyé par Ditch

En tout cas, pour ma part, je partirais sur une solution basée sur un chargement de dll à la volée. Dans ces dll les composants doivent implémenter une interface que tu définis dans un projet quelconque.

Tous les composants doivent implémenter cette interface sans quoi c'est niet. Cela ne devrait pas poser trop de problème. J'avais fait ce système sans le chargement dynamique et ca marchait nickel.

Tu devras cependant faire un gestionnaire de plugins pour persister les informations sur ce que tu veux ou ne veux pas charger.

Que penses-tu de cela?

Cà me semble

Il s'agira maintenant de "recenser les droits" afin de l'attribuer à un autre utilisateur... Enfin, peut être qu'il faudra que je réfléchisse sur les interfaces à définir et j'y verrais plus clair.

Je suis entrain de faire des tests. Je poste les résultats au fur et à mesure.

Merci

**Ditch** · 24/03/2007, 16h41

C'est à ton "moteur" de gérer la gestion des accès. Le plugin ne connait pas la notion d'utilisateur, en tout cas pas la manière dont c'est géré dans l'appli. Si il a besoin d'un utilisateur, tu devras lui passer les infos lors de l'instanciation je pense bien (et pourquoi pas mettre un ou plusieurs objets permettant de définir cela dans ta dll dans laquelle s etrouve l'interface?).

C'est dommage que je n'ai pas le temps pour le moment sinon j'aurais fait un exemple et pourquoi pas même un tuto. Ce sera pour dans 2 mois