Communication entre les modules : Différence entre versions

De OviWiki
Aller à : navigation, rechercher
(→‎Proposer des fonctionnalités)
 
(23 révisions intermédiaires par 3 utilisateurs non affichées)
Ligne 1 : Ligne 1 :
 +
[[Catégorie:Développement de modules]]
 +
[[Catégorie:Technologies à l'étude]]
 +
 +
== Dépendances entre les modules au moment de l'installation ==
 +
 
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" :
 
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 :
+
exemple avec le module dashboard qui nécessite le module client :
 
<pre>
 
<pre>
  
 
[general]
 
[general]
−
name="ivdashboard"
+
name="dashboard"
 
version=6.09
 
version=6.09
−
description="Gestion de projets INVIVO"
+
description="Gestion de projets"
−
db_prefix="ivd_"
+
db_prefix="gdp_"
 
ov_version=5.6.2
 
ov_version=5.6.2
 
php_version=4.1.2
 
php_version=4.1.2
Ligne 18 : Ligne 23 :
 
</pre>
 
</pre>
  
 +
== Gestionnaire d'événements et fonctionnalités ==
  
−
Pour que les différents modules puissent partager des fonctions, les développeurs pourrons utiliser le [[API du gestionnaire d'événement|gestionnaire d'événements]]
+
Pour que les différents modules puissent partager des fonctions, les développeurs pourront utiliser le [[API du gestionnaire d'événement|gestionnaire d'événements]] et l'[[API des fonctionnalités]]
  
 
[[Image:Com addons.svg]]
 
[[Image: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 [http://www.phpdoc.org/ phpdoc] devra être utilisée pour définir le numéro de version du module minimum requis.
 
−
 
−
exemple :
 
−
 
−
<pre>
 
−
 
−
 
−
class forms_interface {
 
−
 
−
/**
 
−
* get form functionality
 
−
* @since 5.0
 
−
* @static
 
−
*/
 
−
function getForm() {
 
−
 
−
}
 
−
 
−
 
−
/**
 
−
* get application functionality
 
−
* @since 5.2
 
−
* @static
 
−
*/
 
−
function getApplication() {
 
−
 
−
}
 
−
}
 
−
 
−
 
−
</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>
 
−
 
−
bab_getFunctionality('convertHtml');
 
−
 
−
class convertToPdf extends convertHtml {
 
−
function getDescription() {
 
−
return 'convertir du html en pdf';
 
−
}
 
−
 
−
function getFunctionalityCallableMethods() {
 
−
return array(
 
−
'process'
 
−
);
 
−
}
 
−
 
−
function process($html) {
 
−
 
−
}
 
−
}
 
−
 
−
</pre>
 
−
 
−
 
−
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.
 

Version actuelle en date du 6 mars 2009 à 11:07


Dépendances entre les modules au moment de l'installation

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 dashboard qui nécessite le module client : 


[general]
name="dashboard"
version=6.09
description="Gestion de projets"
db_prefix="gdp_"
ov_version=5.6.2
php_version=4.1.2
mysql_version=3.23

[addons]
clients=2.8

Gestionnaire d'événements et fonctionnalités

Pour que les différents modules puissent partager des fonctions, les développeurs pourront utiliser le gestionnaire d'événements et l'API des fonctionnalités

Com addons.svg

Récupérée de « https://wiki.ovidentia.fr/index.php?title=Communication_entre_les_modules&oldid=3957 »