Re: avancement des travaux

Olivier Pascal wrote:

>Moi j'attend de voir comment on va gérer la partie administration des modules 
>pour voir comment je vais gérer celle de la conf.
>
>Proposition : une classe principale pour gérer simplement les pages d'admin.
>Truc::SetPage($titre, $contenu_en_xml, $titre_page_parente = null)
>
>Ensuite pour générer l'admin on pourait faire
>
>Truc::GetAllTitles() pour avoir un xml contenant les titres, quelquechose 
>comme ça peut-être :
><titles>
>	<page title="Configuration générale" />
>	<page title="Modstats">
>		<page title="Résumé détaillé />
>		<page title="Configuration" type="conf" />
>	</page>
></titles>
>
>Truc::GetPage("Résumé détaillé") pour avoir la page correspondante :
><page title="Résumé détaillé">
>	<h1>Aujourd'hui</h1>
>	<p>Votre site a reçu XXX visiteurs uniques [...]</p>
></page>
>  
>
par expérience, c'est bien le derniers des soucis les noms et les 
descriptions ... Ce qui est beaucoup plus difficile à représenter, c'est 
les connexions logiques entre les éléments :
le fait qu'un article peut etre associé à plusieurs catégories, le fait 
qu'un article a un seul titre, le fait que l'identifiant de l'article 
doit être unique, le fait que des commentaires peuvent être associés à 
un article, le fait qu'un article peut être publié en plusieurs langues, 
que plusieurs versions peuvent être disponible alors que pour une 
catégorie le versionnement n'a aucun sens ...

C'est vite une très grosse prise de tête, et il faut bien s'organiser 
dès le départ.

RDF me parait très adapté pour faire ce genre de descriptions, mais 
c'est peut-être pas assez au point technologiquement ... Sinon il faut 
se faire une syntaxe bien précise en XML.

J'avais essayé ce genre de descriptions pour faire des boutiques en 
ligne, qui doivent être adaptées à chaque client, mais qui ont des 
caractéristiques communes. Mais c'est un boulot dingue : tout le 
traitement de données, des commandes, où doivent être redirigées les 
infos etc ...

>Les pages ayant l'attribut "type" contenant "conf" peuvent accesoirement être 
>générées automatiquement.
>
>Si ça vous va, il y a un problème auquel je n'ai pas encore bien réfléchi : 
>comment gérer le passage de variables (ex: lorsque je clique sur le liens 
>pour avoir la liste des referers du jour ou lorsque je valide le formulaire 
>de conf).
>  
>
je me suis posé très souvent cette question ces 3 dernières années, et 
je pense être parvenu à une solution. Dans les interfaces d'admin, à 
chaque clic on doit passer une multitude d'informations : gerer tout à 
la main est extrèmement pénible, c'est même une perte de temps.
Mes admins sont représentées comme des arbres : on travaille dans un 
module, qui contient des éléments, qui contiennent eux des sous-éléments 
etc ... Il était donc tout naturel d'organiser les variables en arbre, 
pour conserver les infos de chaque section, pouvoir travailler dans une 
section fille et revenir après.

Voici mon évolution :

La première idée fut d'organiser ca comme un objet de navigation dans 
l'admin : je n'avais pas trop de contrainte de performances, étant donné 
que c'était dans l'administration. J'ai donc fait mes objets. Premier 
problème : les communiquer à la page suivante. Chaque lien dans la page 
possède les infos qui feront avancer vers la section suivante : ca peut 
faire une bonne centaine de liens quand il y a pas mal d'infos. Chaque 
lien contient donc une donnée qu'il faut transmettre si et seulement 
s'il y a un clic : j'ai commencé par placer la donnée dans le lien, 
serialisé dans une variable. C'est moche, ca fait des URI de 3km. Pas 
bon comme technique ! Pourtant passer les infos en automatique comme ca, 
ca me plaisait bien !
2eme évolution technologique : Au lieu de tout stocker dans le lien, je 
place ca dans les sessions. Cependant ca marche bien pour le coup 
suivant en identifiant le lien par son numéro, mais si le client va sur 
une page précédente : patatra !
J'ai donc stocké dans l'URI (avec une correspondance en session) le 
numéro de la page vue et le numéro du lien : ?p=2&n=6 par exemple.
Problème : sur des pages un peu chargées, les sessions explosent ...
3e évolution : comme les sessions c'est trop petit, je fais la même 
chose sur le disque, dans des fichiers !

Constat : c'est pratique pour programmer, on se pose pas de questions 
pour passer des infos puisque c'est automatique. Par contre, c'est moche 
des URI comme ca, et les fichiers sur le disque, ca prend de la place, 
il faut les nettoyer etc ...

J'ai donc décidé de tenter de fonctionner avec des URI qui veulent dire 
quelque chose. Une URI, comme des repertoires, ca représente très bien 
un arbre : pas de pb de ce coté la ! Il faut tout de même passer des 
variables ... j'ai choisi de les passer comme ca : 
/admin/module/section1,liste=ok,affiche=tous/section2

Au final, ca fonctionne très bien, c'est clean, super leger et 
manipulable automatiquement par un script ... Mais pourquoi ai-je 
attendu aussi longtemps pour faire si simple ?!? .... :-\ ouiiinnnn je 
connaissais pas le mod_rewrite ...

Comme quoi, avant de se lancer dans une machine de guerre, faut toujours 
regarder autour de soi !!

-- 
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/