Salut,
A première vue, le ML de Savannah fonctionne car je viens de rcevoir le
digest suivant ....
@ plus,
Aymeric
-----Message d'origine-----
De : address@hidden
[mailto:address@hidden De la part
de address@hidden
Envoyé : jeudi 1 avril 2004 11:34
À : address@hidden
Objet : Ganesha-dev Digest, Vol 1, Issue 1
Send Ganesha-dev mailing list submissions to
address@hidden
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.nongnu.org/mailman/listinfo/ganesha-dev
or, via email, send a message with subject or body 'help' to
address@hidden
You can reach the person managing the list at
address@hidden
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Ganesha-dev digest..."
Today's Topics:
1. Nouveau tutoriel (Pierre-Yves Gosset)
2. Suite de la discussion (Aymeric DURAND)
3. revival !!! (Eric Villard)
----------------------------------------------------------------------
Message: 1
Date: Mon, 29 Mar 2004 17:14:38 +0200
From: Pierre-Yves Gosset <address@hidden>
Subject: [Ganesha-dev] Nouveau tutoriel
To: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Aux membres inscrits :
un nouveau tuto est disponible : "comment modifier la Zodevga² ?"
Rappel : la zodevga est maintenant ici http://www.nongnu.org/ganesha/
Tous les membres peuvent maintenant mettre à jour les pages.
Le tuto est sur http://ganesha.keonox.com/tutoriels/ et est volontairement
détaillé pour ceux qui ont du mal (non non, vous n'aurez pas de nom)
A+
pyg
------------------------------
Message: 2
Date: Wed, 31 Mar 2004 14:14:46 +0200
From: "Aymeric DURAND" <address@hidden>
Subject: [Ganesha-dev] Suite de la discussion
To: <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
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 daccord avec Pierre-Yves car je trouve
relativement intéressant de pouvoir créer des améliorations des fonctions
natives et lexemple 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, jaimerais revenir sur la problématique de la mise à jour des addons
et je me demande sin 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 daller rechercher la nouvelle liste à partir
dun 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mail.gnu.org/pipermail/ganesha-dev/attachments/20040331/2a9eb835/atta
chment.htm
------------------------------
Message: 3
Date: Thu, 1 Apr 2004 12:31:05 +0200
From: "Eric Villard" <address@hidden>
Subject: [Ganesha-dev] revival !!!
To: <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Salut à tous et désolé pour ces 2 jours de silence mais je devais animer une
formation...
Je viens donc de prendre connaissance de tous les débats de façon
chronologique, histoire
de ne pas perdre le fil !!!
Tout d'abord, Bravo Aymeric !!! Doublement, à la fois pour le calendrier et
pour le menu arborescent.
Il serait sans doute intéressant d'essayer de rendre plus générique ce
dernier afin que l'utilisation même
du menu puisse se faire aussi côté tuteur (ou admin pourquoi pas ?). C'est
quand même une fonctionnalité
très intéressante et fort utile.
D'ailleurs par extension ne serait-il pas intéressant d'avoir un système
similaire dans la gestion des modules
de formation ? (Structure + menu d'accès)
En ce qui concerne le calendrier, j'ai quelques idées en tête, mais ce sera
pour plus tard.
Je suis heureux de voir que GASP prend sacrément tournure. L'attente fût
longue avant de pouvoir ouvrir
les v1.1 et 1.2, openoffice oblige !!!
Afin d'alimenter le débat, je suis de l'avis de Pierre-Yves et Aymeric au
sujet de l'intérêt de conserver
$GAD['xxxx']['loadconfig']
Pour $GAD['xxxx']['config'], pas d'avis particulier. Le fait de le conserver
apporte un peu de souplesse mais
en a-t-on besoin, normaliser de temps en temps ne fait pas de mal. De toute
manière d'après les spécifs, l'impact
d'une suppression ou d'un ajout de ce paramètre à l'air d'être confiné à
GASP...
L'idée du FrameWork me paraît primordiale d'ailleurs Georges comment vois-tu
la chose ?
Par contre à ce sujet comment va-t-on gérer les possibilités de conflits
inter-addons ?
Au sujet d'IGASP, je cite Georges :
"Définir un nouvel objet 'extends' IGASP pour pouvoir être appelé
directement à partir de Ganesha."
Je voudrais étendre aussi la réflexion au fait que le problème est dual. Sur
quelle interface de Ganesha
va pouvoir s'appuyer GASP, et par lui, les Addons ?
Parce qu'en fait 2 principes (enfin c'est pas exhaustif !) peuvent être mis
en place :
- le premier plus simple consiste à dire que les Addons gèrent tout leur
fonctionnement de manière autonome
en s'appuyant uniquement sur les méthodes d'affichage de Ganesha pour
pouvoir gérer celui-ci au niveau de la
plate-forme
- le deuxième plus complexe consiste à définir une API plus "riche" afin de
permettre aux Addons de s'appuyer
à travers GASP sur des fonctionnalités de Ganesha et donc de profiter du
"moteur" de la plate-forme.
(c'est celle que je préconiserais)
Je voulais donc savoir comment vous voyez les choses à ce niveau.
En ce qui concerne l'installation/désinstallation d'un Addon, il est à mon
avis préférable de le gérer à travers GASP.
Je pense qu'on peut aisément définir une structure informative (XML ?) sur
laquelle s'appuierait GASP pour
gérer ces évènements. Le fait de rester maître de ce genre d'action évitera
sans doute des problèmes à l'avenir.
Il faudrait aussi que les addons aient leurs propres tables pour les infos
spécifiques.
De toute façon ça risque de devenir inévitable : définir des "contraintes"
de développement pour Addon 'GASP Compliant' !
D'autre part quelqu'un a-t-il statuer au sujet de la possibilité de
s'appuyer sur XML ?
Je suis désolé pour l'instant de ne faire que parler (enfin d'écrire ;)) que
des idées, mais je n'ai pas trop de dispo pour coder !
à mon grand regret d'ailleurs :(
Mais avec mes prochaines vacances (ce SOIR !!!) je devrais avoir plus de
temps pour détailler et implémenter certaines d'entre elles
J'espère donc pouvoir être plus actif ces prochains jours.
Sur ce chers amis,
je vous souhaite une bonne journée
@+
Eric
Éric VILLARD
Société NEF
9 bis avenue de la falaise
38360 SASSENAGE
Tél : 04 76 26 90 28
Fax : 04 76 26 20 48
mailto:address@hidden
http://www.nef.fr <http://www.nef.fr/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mail.gnu.org/pipermail/ganesha-dev/attachments/20040401/5a3a2301/atta
chment.html
------------------------------
_______________________________________________
Ganesha-dev mailing list
address@hidden
http://mail.nongnu.org/mailman/listinfo/ganesha-dev
End of Ganesha-dev Digest, Vol 1, Issue 1
*****************************************