Re: Test du nouveau type d'évenemen t

Olivier Pascal wrote:

>Du nouveau dans
>/head/v2/tmp
>  
>
pour ce genre de tests, ca serait mieux que tu fasse ca dans ton 
repertoire perso que dans le head !

>Bon j'ai fait quelques tests sur le nouveau type d'évenement et ça marche du 
>tonnerre, enfin du concret :-)
>
>D'abord je défini le gestionnaire avec
>$ctrl->setHandler('mod', 'testModule') ;
>soit la classe 'testModule' sous le nom de 'mod' dans le contrÃŽleur
>
>Ensuite je défini l'évenement avec
>$ctrl->setUriEvent('^/blogv2/(.*)', 'mod') ;
>pour matcher les urls qui commencent par /blogv2 et lancer le gestionnaire 
>dénommé 'mod', mais ça vous l'avez compris
>
>Enfin j'exécute le contrÎleur avec
>$ctrl->execute($uri->simple_uri, $uri->params) ;
>en lui passant les bons paramÚtres (voir plus haut la définition de UriParser)
>
>Résultat : si $uri->simple_uri débute par /blogv2, le contrÎleur appelera 
>$testModule->execute() avec 2 paramÚtres :
>- les résultats de la recherche de l'expression rationnelle sur l'uri
>- les paramÚtres de l'uri
>  
>

c'est pas possible de fonctionner comme ca, c'est totalement contraire à 
ce qu'on avait décidé sur le fonctionnement de l'application.

Le controlleur _ne doit pas savoir_ ce qu'il manipule !! La il sait 
qu'il y a des URI, qu'il y a un module mod qui est associé à une URI de 
la forme ^/blogv2/(.*) etc ...

Ce qu'on veut, c'est un controlleur qui puisse tout faire. Avec ce que 
tu propose, on est obligé de fonctionner avec une interface HTTP et une 
URI. Et si on veut implanter un systÚme pour poster un billet par mail 
?? Ca ne fonctionne plus !!

Ce qu'il faut c'est un controlleur capable de faire fonctionner une 
machine à café, pourvu qu'il y ait les modules nécessaires : un module 
pour aller chercher le café dans le placard, un pour le mettre dans la 
cafetiÚre, un pour lancer la cafetiÚre, un pour attendre que le café se 
fasse, et un pour récupérer le café !

Voici ce que je propose et qui me parait être cohérent avec ce qu'on 
avait décidé ...

Le controlleur (initialisé au lancement de l'application, on lui passe 
le type d'interface (interface web pour l'instant)) :
  - un gestionnaire d'analyse de l'URI (UriParser)
  - un gestionnaire qui construit la requete interne en fonction de ce 
que lui passe UriParser
  - un gestionnaire qui vérifie les droits d'accÚs
  - un gestionnaire qui gÚre les documents demandés par l'utilisateur 
(DocumentHandler)
      * ici on passe au niveau module
  - un gestionnaire de transformation
  - un gestionnaire d'envoi
  - un gestionnaire de statistique

voila pour la configuration de base.
Les gestionnaires sont décrits par des fichiers XML comme le veut Eric 
et sont gérés par le controlleur.

Pour ce qui est de DocumentHandler : il travaille sur des modules.

On peut décrire les modules en XML, avec des evenements comme tu as fait 
(que j'appelerais plutÎt des filtres). XML me parait plus adapté : c'est 
une donnée statique vis-à-vis des modules, PHP est utile pour faire du 
dynamique. J'ai pas envie de faire de gros matching en PHP par rapport à 
des chaines fixe, ca ne rime à rien.

Un module peut concerner les catégories, un les articles, un les 
commentaires, un l'admin... C'est suffisament dynamique ainsi : si on 
veut ajouter un forum à l'appli, on ajoute un module forum.

Le module gÚre ses librairies dans libs/ (ce que j'avais appelé plugin). 
Il peut y avoir divers éléments dans modules (par exemple dans le module 
Categories, un élément pour gérer les listes de sous catégories, un pour 
la description d'une catégorie etc ...) La prise en compte de ces 
différents éléments se fait au niveau du filtre :
Si on veut filtrer ce qui correspond à une URI de la forme 
/MaCategorie/, dans la description du module on met qu'il faut charger 
l'élément qui liste les sous catégories et celui qui gÚre les 
descriptions de catégories en leur passant le paramÚtre "MaCategorie". 
C'est DocumentHandler qui appelera les éléments directement suivant le 
filtre.

Les filtres dépendent de la requete interne, ca n'est pas forcément de 
la forme ^/blogv2/(.*). Ceci est trÚs important car ca permettra de se 
servir de l'application depuis un post par mail par exemple qui ne 
contient pas d'URI. Il faudra donc définir une syntaxe générale.

Dans les filtres des modules, on peut définir des priorités comme pour 
les gestionnaires, on peut surcharger certains filtres et celui qui aura 
la priorité la plus haute sera pris en compte.

Lorsqu'on installe un nouveau module, on execute un truc particulier sur 
DocumentHandler et il reconstruit son index de filtres suivant les 
modules en gérant les priorités à ce moment la (il ne faut pas perdre le 
temps de le faire à chaque fois et s'il y a un conflit, je prefÚre avoir 
un warning à ce moment là plutot qu'en fonctionnement, ca permet de 
conserver l'ancienne config le temps de résoudre le pb sans crasher 
l'application).

DocumentHandler fait ca sauce interne : il analyse la requete interne, 
la filtre, appelle les éléments des modules suivant ce qu'il a filtré et 
quand tout le monde a terminé son travail il retourne un XML.

Ensuite, le controlleur continue avec les autres gestionnaires 
(transformation etc ...)

-- 
Grégoire Cachet