Re: avancement des travaux

Olivier Pascal wrote:

>Le Lundi 8 Mars 2004 02:23, Gregoire Cachet a écrit :
>  
>
>>- une base pour l'interface d'administration, afin de voir comment on va
>>éditer les plugins
>>    
>>
>
>Je veux bien m'en occuper; pour la gestion de la configuration au niveau de 
>l'interface d'administration, je propose ça :
>
>En ce qui concerne les fichiers :
>+ plusieurs fichiers de configuration, un fichier pour la configuration 
>globale du moteur et un fichier par plugin
>
>En ce qui concerne l'interface graphique :
>+ plusieurs onglets, un par fichier de configuration
>+ plusieurs paragraphes, un par section de fichier de configuration
>
>En ce qui concerne les formulaires :
>+ pour les entrées de type texte, un textarea
>+ pour les entrées de type numérique, un input
>+ pour les entrées de type booléennes, deux boutons radio Activé / Désactivé
>+ pour les tableaux de données, une liste de sélection avec possibilité 
>d'ajouter ou de supprimer, et accessoirement de monter / déscendre si l'ordre 
>est important
>
>
>L'interface de modification de la configuration est donc créée à la volée.
>Mais que dois renvoyer ma classe ? Quel syntaxe utiliser pour décrire les 
>formulaires ?
>
>
>  
>
Je vois 3 manières de fonctionner :
1/ On créé des fichiers de description des zones d'administration (par 
exemple en XML) et on génère des classes à partir de ca

2/ On écrit les classes à la main, en utilisant des sortes de widget 
globaux : formulaire, champ texte, champ numérique etc ... mais aussi 
listes de données, selecteur, filtres, et systemes de selection ou 
édition avancés, par exemple pour rechercher un fichier à inclure, 
ajouter un fichier au document, editer un fichier de mise en page.

3/ On fait tout au coup par coup

La 1/ me parait avoir peut d'interet pour le projet : tout automatiser 
demande beaucoup de programmation pour pas grand chose au final, surtout 
qu'on ajoutera pas 50 modules ...

Actuellement, j'utilise la 2/ en simplifié et en mal concu sur mes 
systèmes. C'est puissant, ca permet de developper vite, c'est très 
orienté objet. Je fonctionne par section, sous-sections, 
sous-sous-sections ... En gros j'edite un élément, je peux éditer les 
éléments liés à l'élément, et ainsi de suite : mon administration est un 
arbre en fait. J'ai un systeme pour construire des URL afin de passer 
les infos necessaires à la navigation en fonction de la position dans 
l'arbre automatiquement.
Pour chaque élément, je peux définir des actions : editer, supprimer, 
activer, visualiser, ou tout ce que je veux.

La 3/ est très rapide à developper. Ca peut suffire si on veut faire une 
release vite. Par contre, on sera vite dépassé, donc il faut garder à 
l'esprit que ce n'est que provisoire.

>>- une idée de la gestion de l'authentification
>>    
>>
>
>Déjà on utilise les sessions de PHP 5, on crée notre propre gestionnaire de 
>sessions ou alors on en utilise un existant ?
>  
>

je suis pas trop pour les sessions : le fonctionnement est un peu lourd, 
on peut pas se permettre de passer les sessions par l'URL avec notre 
système ... Bref, je n'aime pas ca !
Un existant : il en fera surement plus que ce qu'on a besoin, on ne 
maitrisera surement pas tout, et je prefere rester entièrement maître de 
ce que je fais à ce niveau.

En gros je suis pour écrire quelque chose de simple : Pour identifier, 
on peut faire un cookie (de toute facon, c'est dans l'admin) avec le 
pseudo et une clé générée aléatoirement pour le pseudo. Ca permet 
d'identifier sans risque d'erreur et on ne passe pas le mot de passe en 
cookie. Comme ca, si le mec a un pb avec sa session, il la détruit et 
pas besoin de changer le mot de passe.

Ensuite, il faut voir comment on gère les droits d'accès. J'imagine un 
truc du genre de ce que j'utilise actuellement : on travaille par zone 
(blog, admin ...) et on définit des groupes d'utilisateurs (anonyme, 
inscrit, modérateur, rédacteur, administrateur). Pour chaque groupe et 
chaque section on peut associer 3 types de droits : lire, écrire, modérer.

C'est très inspiré du système UNIX, et je n'ai jamais été limité jusqu'à 
présent avec ca.


-- 
Grégoire Cachet - Développeur intégrateur chez Audacy
http://www.zwiffer.org           http://www.audacy.fr
Mangeur de cigogne    http://mangeur-de-cigogne.info/