Re: Test du nouveau type d'évenemen t

Eric Daspet wrote:

>>Dans la définition du 
>>module, on mettra qui doit faire quoi pour tel type de requete ?
>>    
>>
>
>Même pas. Le premier gestionnaire s'exécute, il regarde comme un grand 
>si il y a une catégorie de spécifiée, et si oui il traite la chose en 
>enregistrant la catégorie demandée.
>Les autres suivent le même principe en relisant cette info, et si elle 
>est présente font leurs actions.
>Si aucune catégorie n'est demandée il retourne tout de suite sans rien 
>faire.
>
>Du coup il il n'y a nulle pas besoin d'aller dire à qui que ce soit ce 
>qu'il doit faire. Chacun lit les données et décide en fonction ce qu'il 
>doit faire ou pas. Moins il y a de controle central moins on aura de 
>problÚme pour gérer les organisations.
>
>  
>
le premier gestionnaire qui s'execute, c'est ce que j'appelle 
DocumentHandler.
En fait, il faut bien quelqu'un pour lire la requete interne et dire qui 
doit intervenir en chargeant les intervenants dans le controleur, non ?
Parce que si tout le monde intervient et lit la requete interne en se 
disant "est-ce que je dois intervenir la dessus ?", ca risque non 
seulement d'être un peu le bazar, mais en plus on va avoir des 
performances desastreuses.

C'est pour ca que je propose d'utiliser la méthode des filtres 
d'Olivier, mais de le faire au niveau du XML de description du module : 
dans ce XML, on dit : tu fais intervenir ce gestionnaire s'il y a ca 
dans la requete interne. Ainsi, on contruit la liste lors d'une 
reconfiguration de l'application, et ca reste performant.

Ce n'est qu'une proposition, peut-être as-tu quelque chose de plus 
concret à proposer Eric ?

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