Re: Test du nouveau type d'évenemen t

Grégoire Cachet wrote:
> 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.

Pour le bazar je ne pense pas. Je continue à penser que moins on 
s'occupe d'organisation centrale, moins on aura de problÚme à gérer les 
différents cas.

Pour les perfs je suis totalement d'accord, je te laisse voir mon autre 
mail à ce sujet.

> 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 que vous voulez faire c'est gérer X types de requêtes internes et 
lancer une file de gestionnaire différente suivant ce type ? (si c'est 
une section "administration" on lance la file "administration", si c'est 
une section "index" on lance l'événement "index" ....)

Techniquement ça me parait clean (à vrai dire ce n'est pas bien 
complexe, il suffit de faire un gestionnaire qui redirige les requête 
dans telle ou telle file), je vous laisse regarder mon autre mail et on 
discute des diverses options.

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


-- 
Eric