[Ganesha-dev] Suite de la discussion

[Aymeric DURAND]

At 11:35 31/03/2004, you wrote:

>Bonjour,

>C'est une excellente base de travail.

>On a déjà deux projets pour valider le fonctionnement de GASP (arbo +

>quickstat (PYG))

 

J'ajoute Moolinex et Lanceur, déjà compatible GASP 1.0

 

>J'ai fait qques petites modifications. Rien d'exceptionnel.

Une remarque : je vois notamment :

 

"* Si le nom du fichier est toujours config.inc.php, on n'a pas besoin de

la variable $GAD['lanceur']['config']. Il suffit de tester la presence d'un

fichier avant de l'inclueder et on ne devrait plus avoir besoin de

$GAD['lanceur']['loadconfig'] "

 

Tout à fait, si tout le monde est d'accord, on peut partir du principe que

si addon nécéssite un fichier de config, celui ci aurait systématiquement

pour nom config.inc.php. Moi, ça ne me dérange pas.

 

Par contre, le loadconfig avait un autre but : inclure systematiquement le

contenu du fichier de config à chaque appel de anema.inc.php. Imagine que

tu veuille réecrire ta fonction de formattage de temps (format_time, je

crois), tu peux créer un addons "time" (en fait un patch) contenant un

fichier config.inc.php avec la nouvelle fonction "format_time_amelioré" et

en ajoutant dans l'ancienne format_time une condition :

format_time($var) {

   if (GAD_TIME) { return format_time_amelioré($var); } else {

     //ancien code

   }

}

A chaque appel de format_time, c'est format_time_amelioré qui est executée.

Je trouve ça TRES TRES pratique.

 

>> Personnellement, je suis d’accord avec Pierre-Yves car je trouve relativement intéressant de pouvoir créer des améliorations des fonctions natives et l’exemple du temps est très pertinent.

 

 

 

Le loadconfig  est là pour dire si le fichier doit systematiquement être

inclu ou non, par exemple il n'y a aucun interêt à inclure systematiquement

le config.inc.php de quickstats ou de moolinex, par exemple.

 

 

>Par contre PYG pose une question très intéressante : Qu'est-ce qu'un

>addon?

 

Je donne ma version et j'attend les votres ;-)

un addon est un "ensemble de code" ajoutant des fonctionnalités à Ganesha. L'addon peut-être :

- une mini-application "indépendante" liée par GASP à Ganesha : Quickstats,

INSC, Moolinex qui pourraient fonctionner dans une popup indépendante, sans

liaison directe avec la plateforme.

- une ensemble de fonctionnalités, "surcouche" de ganesha : arborescence,

calendrier, etc. On modifie alors des fonctionnalités prééxistantes

- une modification/ajout spécifique de fonctionnalités préexistantes : cas

du format_time cité plus haut.

 

 

>> pour moi, un addon est toute évolution qui peut-être apportée au fonctionnement initiale de Ganesha donc cela comprend :

1-    nvelle donctionnalités ou application spécifique(moulinex, calendrier ….)

2-    une surcouche aux applications existantes de Ganesha

 

Enfin, j’aimerais revenir sur la problématique de la mise à jour des addons et je me demande s’in ne serait pas intéressant de basculer sur une liste rendeignée dans la base de données et ajouter une fonctionnalité dans le profil admin qui lui permette d’aller rechercher la nouvelle liste à partir d’un script externe et de choisir les options à rajouter dans sa base de données ?

 

Je peux plancher sur ces specs si cela vous semble pertinent.

 

A plus,

 

Aymeric.