Discussion :

[Giovanny Temgoua]

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]

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]

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]

Bonsoir,

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

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]

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]

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.