Re: Test du nouveau type d'évenemen t

Olivier Pascal wrote:

>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.
>  
>
DocumentHandler pourrait correspondre au gestionnaire qui décide qui 
doit être inséré dans la page. Ainsi, il place un objet dans le 
controleur qui contient l'embryon de sortie de l'application, et quand 
les gestionnaires suivants (qui générent du contenu) s'executent, ils 
concatÚnent leurs sorties sur cet objet via une methode apropriée.

>>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 ?
>  
>
Disons qu'il me semble plus simple d'administrer l'application avec une 
découpage en modules, si besoin dépendants entre eux. En fait, il suffit 
que ceux-ci fournissent une interface. Si on veut changer la facon de 
travailler avec les catégories sans changer l'interface d'accÚs aux 
catégories, on peut le faire sans toucher aux articles, billets du blog 
etc ...
Par exemple, dans les sites que je fais pour des clients, en gros il y a 
toujours la même chose, seulement le nom des données, le nombre de 
champs, s'il faut une image ou non varie. Utiliser des modules à ce 
niveau permet de développer avec beaucoup plus de souplesse : si je veux 
mettre des news sur la page d'accueil, je suis pas obliger de changer ma 
boutique electronique ... Si on commence à tout relier, ca foire vite, 
et on perd l'interet du module.
Si tu fais un module pour ce qui est du domaine du HTTP, puis un 
l'authentification, un pour les stats et enfin un pour les données 
(catégories, articles ...), la gestion modulaire n'apporte rien : en 
général ce qu'on va changer, c'est dans les données ... Si on veut 
contruire une gestion puissante des modules, avec des relations de 
dépendance etc, autant que ca serve.

>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 :-)
>  
>
Pour des raisons de performance et de maintenance du code. En effet, 
charger une classe avec les outils d'écriture est beaucoup plus long 
qu'une bete classe capable de lire la donnée. Ensuite, pour maintenir le 
code, on sait directement ou trouver l'information, pas besoin de 
chercher dans un fichier de 3 km ...

>>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 ?
>  
>
Je voulais parler de type au niveau de ce que contient la requete 
interne : c'est une requete pour une catégorie ? Pour administrer le 
site ? etc ...

Bon, il me semble que ca prend forme tout ca ! ;-)

>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 ;-)
>  
>
ohh, pour ce que j'y traine ...

Tu peux me croiser sur #openweb sur le serveur de freenode

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