Re: [Dolibarr-dev] Gestion de projet

[Roland Mas]

Eldy, 2005-04-20 22:16:43 +0200 :

[...]

> C'est ca.

> Toute action Dolibarr (disons les principale actions métiers,
> création/modification/suppression d'une
> commande/facture/société/produit) appellerait une méthode
> "run_triggers" (avec un s) en envoyant 5 paramètres: un code propre
> à l'action, l'objet concerné par l'action, la variable $langs, $user
> et $conf.
> Libre ensuite à l'intégrateur de placer dans le répertoire
> includes/modules/triggers un fichier php (ou plusieurs) qui
> contiendrait une methode run_trigger (sans le s cette fois). La
> methode run_triggers (avec le s) appellerait toutes les methodes
> run_trigger (sans s) qu'elle trouve dans ce répertoire (si elle en
> trouve). L'intégrateur y met le code qu'il veut dans cette
> fonction. Et comme cette fonction reçoit le code de l'évênement
> Dolibarr, l'objet concerné et la conf et la langue de l'utilisateur,
> il peut en faire ce qu'il veut pour une interaction avec
> l'extérieur.

  Ça ressemble un peu à ce que j'avais implémenté dans Gforge.  Comme
je préfère ma solution, je vous l'expose, après vous faites ce que
vous voulez :-)

  Le concept : des plugins s'enregistrent dans une table de la BD,
avec un fichier PHP qui instancie une classe dérivée d'une classe
Plugin générique.  Cette classe contient obligatoirement trois
méthodes (en plus du constructeur) : GetHooks, GetName et CallHook.
GetName renvoie juste le nom du plugin, GetHooks renvoie une liste de
noms de "hooks" auxquels le plugin s'abonne, et CallHook exécute du
code.

  Dans le code de Gforge, on a ajouté au fil des besoins des appels à
une fonction plugin_hook, en lui passant un tableau associatif de
paramètres à chaque fois.  Du coup, à chaque hook est associé un jeu
de paramètres qui peut varier selon les besoins.

  On a une classe PluginManager, qui regarde quels plugins existent,
qui les instancie, et qui stocke pour chacun la liste des hooks
concernés en appelant leur méthode GetHooks.  Quand le code appelle la
fonction globale plugin_hook, c'est l'objet PluginManager qui va
appeler les méthodes concernées, avec deux arguments : un nom de hook,
et un tableau de paramètres.

  C'est à la fois plus rigide et plus souple que la solution
proposée : plus rigide, parce qu'il faut définir les hooks à la main
quand le besoin s'en fait sentir ; plus souple, parce que les listes
d'arguments peuvent varier d'un hook à l'autre (tout le contexte
n'existe pas sur toutes les pages).  L'expérience montre que pour
l'instant, dans Gforge, ça nous a toujours suffi -- et on commence à
avoir plusieurs plugins qui se baladent dans la nature...

  Si vous voulez voir l'implémentation :
http://gforge.org/plugins/scmcvs/cvsweb.php/gforge/common/include/?cvsroot=gforge
Je vous recommande en particulier common/include/Plugin.class et
common/include/PluginManager.class, ainsi que www/include/Layout.class
pour quelques exemples d'appel d'un hook.

  Voili voilà.

Roland.
-- 
Roland Mas

Sauvez un arbre, tuez un castor.