Communication entre les modules : Différence entre versions
(→DRAFT : API d'appel de fonction direct entre les modules) |
(→Proposer des fonctionnalités) |
||
| Ligne 99 : | Ligne 99 : | ||
<pre> | <pre> | ||
| − | + | bab_getFunctionality('convertHtml'); | |
class convertToPdf extends convertHtml { | class convertToPdf extends convertHtml { | ||
Version du 12 décembre 2007 à 16:39
Lors de l'installation d'un module, des dépendances peuvent êtres utilisées, le nom des modules dépendants doivent être ajoutés dans le fichier addonini.php avec le numéro de version minimum nécessaire dans la section "addons" :
exemple avec le module ivdashboard qui nécessite le module client :
[general] name="ivdashboard" version=6.09 description="Gestion de projets INVIVO" db_prefix="ivd_" ov_version=5.6.2 php_version=4.1.2 mysql_version=3.23 [addons] clients=2.8
Pour que les différents modules puissent partager des fonctions, les développeurs pourrons utiliser le gestionnaire d'événements
DRAFT : API d'appel de fonction direct entre les modules
Proposer des fonctionnalités
Chaque module proposant une ou plusieurs fonctionnalités disponibles pour les autres modules devra contenir un fichier "interface.php" avec un objet contenant des méthodes statiques.
Le nom de l'objet sera crée à partir du nom du module de la manière suivante : addonname_interface
La syntaxe phpdoc devra être utilisée pour définir le numéro de version du module minimum requis.
exemple :
class forms_interface {
/**
* get form functionality
* @since 5.0
* @static
*/
function getForm() {
}
/**
* get application functionality
* @since 5.2
* @static
*/
function getApplication() {
}
}
La liste des fonctionnalités disponibles pour chaque modules sera enregistrée en base de donnée par le noyau au moment de l'installation du module.
Chaque méthode statique qui correspond à une fonctionnalité devra obligatoirement retourner un objet qui suis une structure bien précise avec des méthode obligatoires, l'objet devra être hérité de bab_functionality.
exemple : le module "convert" propose une fonctionnalité pour convertir du html
class convertHtml extends bab_functionality {
function getDescription() {
return 'convertir du html vers un autre format';
}
function getFunctionalityCallableMethods() {
return array(
'process'
);
}
function process($html) {
return NULL;
}
}
Dans un autre module "convertToPdf", on propose de convertir du html en pdf, pour que la fonctionnalité soit acceptée par le programme d'installation, l'objet doit contenir les mêmes méthodes
bab_getFunctionality('convertHtml');
class convertToPdf extends convertHtml {
function getDescription() {
return 'convertir du html en pdf';
}
function getFunctionalityCallableMethods() {
return array(
'process'
);
}
function process($html) {
}
}
Pour simplifier l'execution des fonctions d'interface, le contexte du module ne sera pas recréé avant que la fonction soit appelée, par conséquent, l'utilisation des variables globales de l'environnement du module ne devrons pas être utilisées.
Appeler une fonction
Lors de l'appel d'un fonctionnalité, les droits ACL du module, il faut utiliser la fonction bab_getFunctionality() avec comme paramètre le nom de la fonctionnalité, la fonction revoie une instance héritée de bab_functionality ou NULL si la fonctionnalité n'est pas accessible.
Pour obtenir la liste des fonctionnalités héritée d'une autre, utilisez bab_fonctionalities() qui retourne un tableau.