Communication entre les modules : Différence entre versions

De OviWiki
Aller à : navigation, rechercher
(Proposer une fonction)
(DRAFT : API d'appel de fonction direct entre les modules)
Ligne 27 : Ligne 27 :
 
== DRAFT : API d'appel de fonction direct entre les modules ==
 
== DRAFT : API d'appel de fonction direct entre les modules ==
  
=== Proposer une fonction ===
+
=== Proposer des fonctionnalités ===
  
Chaque module proposant une ou plusieurs fonctions disponibles pour les autres modules devra contenir un fichier "interface.php" avec un objet contenant des méthodes statiques.
+
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
 
Le nom de l'objet sera crée à partir du nom du module de la manière suivante : addonname_interface
Ligne 43 : Ligne 43 :
 
 
 
/**
 
/**
* get form object
+
* get form functionality
 
* @since 5.0
 
* @since 5.0
 
* @static
 
* @static
 
*/
 
*/
function getForm($id_form) {
+
function getForm() {
 +
 +
}
 +
 
 +
 
 +
/**
 +
* get application functionality
 +
* @since 5.2
 +
* @static
 +
*/
 +
function getApplication() {
 
 
 
}
 
}
Ligne 55 : Ligne 65 :
 
</pre>
 
</pre>
  
 +
 +
 +
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
 +
 +
<pre>
 +
 +
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;
 +
}
 +
}
 +
 +
</pre>
 +
 +
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
 +
 +
 +
<pre>
 +
 +
$obj = bab_getFunctionality('convertHtml');
 +
 +
class convertToPdf extends convertHtml {
 +
function getDescription() {
 +
return 'convertir du html en pdf';
 +
}
 +
 +
function getFunctionalityCallableMethods() {
 +
return array(
 +
'process'
 +
);
 +
}
 +
 +
function process($html) {
 +
 +
}
 +
}
 +
 +
</pre>
  
  
Ligne 61 : Ligne 124 :
 
=== Appeler une fonction ===
 
=== Appeler une fonction ===
  
Lors de l'appel d'un fonction d'un autre module, les droits ACL du module cible sont testés, il faut utiliser la fonction bab_callAddon() avec les paramètres suivants :
+
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.
  
* nom de l'addon
+
Pour obtenir la liste des fonctionnalités héritée d'une autre, utilisez bab_fonctionalities() qui retourne un tableau.
* nom de la méthode
+
* ... (un ou plusieurs paramètres qui serons passés à la méthode cible)
+

Version du 4 octobre 2007 à 09:20

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

Com addons.svg


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



$obj = 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.