Re: Test du nouveau type d'évenemen t

Olivier Pascal wrote:

>Décidemment je perd pied... désolé :S Apparement tu invalides les 3 
>définitions ci-dessous alors ?
>
>  
>
>>- controleur : une classe qui se charge de lancer les gestionnaires un à
>>un, et de servir de stockage pour les données échangées entre ces
>>gestionnaires
>>
>>- gestionnaire (handler) : une classe qui fait une action unique. Par
>>exemple la classe qui lit le nom du billet à aller chercher et renvoie
>>un objet document au contrÃŽleur est un gestionnaire
>>
>>- module : un groupe de fichiers qui regrouppe plusieurs gestionnaires,
>>fichiers de configurations et données annexes. Par exemple un module qui
>>compte le temps passé sur chaque page et le met dans un fichier de log
>>contiendra 3 gestionnaires (un pour initialiser le compteur au début, un
>>pour stopper le compteur à la fin, et un pour enregistrer le résultat
>>dans le fichier de log) et un fichier de configuration (pour déterminer
>>l'adresse du fichier de log).
>>    
>>
>
>  
>
je ne remets pas en cause les deux premiÚres définitions.

Apres discussion rapide avec Eric hier soir et relecture des anciens 
mails j'ai compris mon erreur vis à vis des modules. Je ne me souvenais 
plus du concept de modules qui regroupaient des gestionnaires. C'est ca 
le pb des projets qui avancent trop lentement ;-)

En gros, DocumentHandler décide de ce qui doit être intégré dans la 
sortie vis-à-vis de la requete interne et l'ajoute dans l'execution du 
controleur, c'est ca ?

En fait, le fonctionnement qui avait été proposé est trÚs *plat*, à la 
différence de ce que j'imaginais. Il me semblait plus logique de faire 
fonctionner ce que j'appelais *module* sur un autre niveau parce que 
dans ma logique, ce qui gÚre l'affichage d'un article n'est pas sur le 
même plan que ce que ce qui gÚre l'authentification de l'utilisateur ...

Voici ce que j'avais présenté à ce sujet :
http://v2.dreams4net.com:7390/svn/user/GregoireCachet/v2/conception/architecture_blogv2.png

Cependant, il est aussi clair qu'un seul systÚme d'execution est plus 
simple à mettre en place et évite de nombreux bugs. Dans lon idée, on 
aurait eu un ordonnancement au niveau du controleur et un au niveau de 
DocumentHandler qui aurait lancé mes *modules* pour construire 
l'information.

Ce fonctionnement *à plat* me convient aussi. Il est plus général aussi 
finalement.

Pour résumer :
on a le controleur
on a les gestionnaires gérés par le controleur
on a les modules, qui sont un regroupement *virtuel* de gestionnaires 
dans le sens où la notion de module n'intervient pas dans l'execution, 
simplement dans le regroupement logique de l'ensemble ?

On peut donc envisager un module web qui contient des gestionnaires pour 
gérer les URI, gerer les envois au clients, c'est ca ?

Si je veux gérer les catégories, je créé un module qui contient un 
ensemble de gestionnaires capables de gérer les catégories : liste de 
catégories, description d'une catégories etc ? Dans la définition du 
module, on mettra qui doit faire quoi pour tel type de requete ?

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