Re: Mise au clair personnelle

Olivier Pascal wrote:

>Le Samedi 3 Avril 2004 16:27, Gregoire Cachet a écrit :
>  
>
>>eh non ... y a un pb de nommage entre ma dénomination plugin/modules et
>>la votre ...
>>    
>>
>
>Bon je vais essayer d'être clair une fois pour toute sur ma maniÚre de voir 
>les choses :-) peut-être que je suis complÚtement à coté de la plaque (c'est 
>le momment de corriger), mais depuis le début d'aprÚs moi on va dans ce sens 
>là et au bout on devrait avoir quelquechose de fonctionnel.
>
>----
>
>D'un coté on a une librairie standard de classes qui permettent à tous les 
>modules d'accéder aux données de la même maniÚre (une classe pour la conf, 
>une classe pour la base de données, etc.). C'est le niveau le plus bas et à 
>ce stade les données ne représentent rien de spécial).
>
>Ensuite on a les modules qui accÚdent aux données via cette librairie. Ces 
>modules assument des tâches précises, comme le module core ou le module 
>admin.
>
>L'appli peut fonctionner sans modules mais elle joue presque le rÃŽle d'un 
>framework.
>  
>

jusque la, on est OK.

>Parmis tous les modules, le module principal (core) va servir d'interface 
>entre les requêtes des utilisateurs et les classes qui manipuleront les 
>données (à ce stade la donnée représente déjà quelquechose : des documents). 
>Ce module contiendra ses propres classes pour mener sa mission à bien (une 
>classe pour parser l'uri, des autres pour l'interpréter : récupérer un 
>document, une liste de documents, gérer des fichiers joints, etc.).
>
>  
>
bon, la je pense qu'il faut couper en morceaux ... ou bien appeler ca le 
core, mais de toute facon, il ne va pas tout gerer tout seul, ca rime a 
rien ...

a mon avis, faut découper (j'utilise ta dénomination module) :

- un module pour parser l'URI
- un module pour l'interpreter
- un module pour savoir ce qu'il faut récuperer comme documents
- un module pour faire les transformations
- etc ...

Pour ce qui est de l'admin, je pense que ca ne doit pas être un module 
particulier, simplement une requete interne ... Pourquoi gerer 
l'administration sur un autre niveau ?

>L'organisation des modules est orchestrée par un controleur.
>
>----
>
>De mon coté je me suis occupé de la classe qui gÚre la conf : c'est concrêt et 
>fonctionnel, ok.
>
>Eric s'occupe du controleur. Je ne sais pas s'il a terminé et ça me parait un 
>peu abstrait, mais j'essaye d'en tirer quelquechose, j'ai un peu compris le 
>truc. Il doit juste manquer les méthodes pour gérer les évÚnnements de 
>maniÚre relative.
>
>Déjà ces deux choses me paraissent clair.
>  
>
pas de pb de ce coté la.

>Grégoire s'occupe de la partie gestion des données. Je vois pleins de choses 
>interressantes mais j'ai malheureusement du mal à faire l'analogie avec mon 
>schéma ci-dessus :-(
>Quand je regarde un peu tes classes et ton arborescence il me semble que tu 
>travailles déjà pour le core. Soit c'est ça soit mon schéma ci-dessus est 
>incorrecte et j'ai encore rien compris.
>  
>
je travaille effectivement pour ce que tu veux intégrer au core.

>Maintenant, je vois chez vous deux des morceaux de code pour gérer les 
>modules, et ça par exemple ça me trouble. Sans doute est-ce dû à la 
>définition des modules de Gregoire non pas erronée mais différente de la 
>mienne. Je vois aussi chez Eric des classes pour gérer la configuration, avec 
>ni le même nom ni la même syntaxe que inihandler et d'autres choses qui me 
>semblent toujours obscures.
>  
>

Je travaille au niveau des documents.
J'ai décomposé le travail sur les documents en 2 étapes :
- les plugins, qui ont un fonctionnement trÚs générique et qui sont 
capables de lister la donnée correspondant à une requete par type (pour 
les catégories par exemple)
- les modules, qui mettent en forme la donnée renvoyée par le plugin et 
qui gÚre le cache au niveau donnée

Il faut qu'on trouve des noms pour ces deux étapes, si elles vous 
conviennent, afin que l'on puisse les intégrer dans l'application

>Je trouve aussi que ce serait bien que l'on décide ensemble ce qu'il faudrait 
>faire, et comment il faudrait le faire, et non pas le faire dans l'obscurité 
>chacun un peu de son coté, non ?
>  
>
c'est essentiel pour continuer, en effet.

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