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. _______________________________________________ Dolibarr-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
