[AlternC-dev] Développement du webui de la v2

Retour à l'archive de la liste
Le site d'AlternC
Google Custom Search

Nahuel ANGELINETTI nahuel at altnetvision.info
Lun 5 Mar 23:28:00 CET 2007


Salut tout le monde,

Hier, j'ai commencé le développement ( de mon coté ) de la version 2
d'AlternC, en débutant par l'interface web.
J'ai commencé par l'authentification ( PEAR::Auth ), gestion de la
configuration ( /etc/alternc/ | PEAR::Config en utilisant un
formation XML pour les fichiers de conf, qui propose la meilleure
organisation des données de configuration ), et je suis en train de
m'attaquer à la partie modules. Et tout ça en utilisant le fameux
phpSavant que je trouve super ( merci anarcat ) :)

Pour le moment, je voyait cette gestion de conf, un peu comme
l'actuelle, sauf que l'ont peut décider dans le fichier de
configuration quels seront les modules activés.
Cela irait donc chercher les fichiers php du module dans
(repertoiredinstallalternc)/bureau/modules/nomdumodule/

Maintenant je me retrouve face à une question d'organisation des
modules, pour rendre générique cette gestion.
En particulier pour les parties web du module ( la principale partie ),
et encore plus en particulier, le nom complet du module et les liens.
Et ne pas oublier, qu'il faut gérer les traductions après, et donc
comment on stocke les traductions, comment on stocke les traductions
des modules, etc ...

Mes solutions :

  * Les traductions :
	Celle ci serait géré à chaque module, ( en sachant que le
bureau est représenté par un module ) dans des fichiers spécifiques
dans un répertoire spécifique, en utilisant une classe qui récupère les
traductions. Par exemple $langue->recupText('indexDuString','fr_FR');
Tout les traductions seront donc en UTF-8 pour la propreté de
l'accessibilité.
Pour le stockage des traductions, cela peut se faire dans un fichier
XML, ou une base de donnée, ce qui me plait dans cette idée, c'est
que PEAR a des librairies de gestion des traductions, il n'y aurait
plus qu'à faire une classe d'abstraction.

  * Les Modules :
	Cela rentre dans la suite du point sur les traductions, il faut
que le menu soit traduit, donc il faudrait qu'il y ai dans un fichier
( en XML ? ) la définition du menu, et donc les "strings" soit liés à
une valeur dans le fichier de traduction.
Ce fichier serait donc un truc du style menu.xml dans la racine du
module.

Mon point actuel de questionnement et sur la gestion du contenu d'un
plugin, comment le contenu du menu est géré ? Avez vous des idées,
mieux que les miennes ?

J'attend vos suggestions.

@plush 

-- 
Nahuel ANGELINETTI
Association ~altNetVision
Jabber/XMPP : nahuel at ahtna.org



Plus d'informations sur la liste de diffusion Dev