Communication entre les modules : Différence entre versions

Version du 12 décembre 2007 à 17:36

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 fonctionnalité devra être nommée selon un "chemin", par exemple "convertHtml/toPdf/openOffice", les caractères _ sont interdis dans le chemin

une fonction du noyau d'ovidentia permettra d'enregistrer un fichier php en tant que fonctionnalité, le fichier devra contenir une classe PHP nommée en utilisant la même arborescence, par exemple :

class convertHtml_toPdf_openOffice extends bab_functionality {

}

le _ remplace le / dans le nom de la classe l'objet devra être hérité de bab_functionality.

au moment de l'installation ou du programme de reprise, il faut enregistrer la fonctionnalité dans ovidentia, exemple :

bab_registerFunctionality("convertHtml/toPdf/openOffice", $GLOBALS['babAddonUrl'].'convert.php');

Dans Ovidentia, un fichier "interface" sera créer dans un arbre de répertoire avec pour contenu du code php pour inclure le fichier passé en 2eme paramètre. La fonction du noyau bab_getFunctionality('convertHtml/toPdf/openOffice'); effectuera une inclusion du fichier "convertHtml/toPdf/openOffice/interface" ensuite l'objet convertHtml_toPdf_openOffice sera instancié.

Les niveaux supérieurs de l'arborescence serons complété avec une copie du fichier interface si aucun fichier interface n'est présent.

Un formulaire sera disponible pour d'administrateur afin de changer les fichiers interface des niveau supérieurs pour rédéfinir les fonctions par défaut dans le cas de sous répertoires multiples.

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 en utilisant openOffice, pour que la fonctionnalité soit acceptée par le programme d'installation, l'objet doit contenir les mêmes méthodes, la liste des méthode sera comparée en utilisant "getFunctionalityCallableMethods"

bab_getFunctionality('convertHtml');

class convertHtml_toPdf_openOffice 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.