Re: Test du nouveau type d'évenemen t

Olivier Pascal <[email protected]> Thu, 8 Apr 2004 22:00:57 +0400
Newsgroups gmane.comp.web.blogv2.devel
Message-ID <[email protected]>
Le Jeudi 8 Avril 2004 19:44, Grégoire Cachet a écrit :
> 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 ?

J'ai jamais trop entendu parlé de DocumentHandler sur la liste je ne pourait 
donc pas te répondre, mais je pense que la décision de générer une sortie 
(XML) ou pas ne revient qu'aux modules : s'ils sortent qch, ce qch devrait 
être concaténé aux sorties des modules précédents pour être traité à la fin 
par le module de transfo.

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

Ta premiÚre phrase est exacte. D'autre part le module d'authentification 
pourait trÚs bien retourner qch lui aussi...

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

Exact. Le module X pourait théoriquement trÚs bien définir un évenement 
faisant appel à un gestionaire du module Y.

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

Oui. Quoi que en pratique ça devrait être séparé en 2 modules au moins, un 
module pour choisir l'interface, et un autre pour gérer les thÚmes (du point 
de vue de l'utilisateur; pour nous ça serait plutÎt UriTruc et 
TransfoMachin).

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

Par exemple ! Mais si tu fais un module pour gérer les catégories et un autre 
pour gérer les articles, l'un devrait pouvoir fonctionner dans l'autre non ? 
sinon quel intéret de séparer les deux pour finalement les rendre dépendants 
l'un de l'autre ?
Une question pas trop en rapport : pourquoi ne pas mettre les fonctions de 
lecture et de description (etc.) des carégories dans une même classe ? Ou 
bien c'est possible aussi de regrouper les classes pour gérer les catégories 
dans un sous-répertoire de /lib d'un module pourquoi pas. Enfin tout ça pour 
faire plus propre :-)

> Dans la définition du
> module, on mettra qui doit faire quoi pour tel type de requete ?

Quelle sorte de type ? De toute maniÚre vu que la requête interne sera 
standardisée il n'y aura qu'un seul type ! Pour l'interface web par exemple 
c'est UriParser qui se chargera de standardiser la requête. Il y aura aussi 
un fichier d'initialisation par interface, par exemple le fichier d'init pour 
l'interface mail ne pourait gérer que l'insertion d'articles. Ça répond 
à ta question ?


Grégoire, c'est quoi l'adresse du serveur irc où tu traines tout le temps ? Ça 
serait plus approprié pour s'expliquer et trol^Mdiscuter parfois ;-)

-- 
Olivier Pascal