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