Re: Test du nouveau type d'évenemen t

Le Jeudi 8 Avril 2004 22:51, Grégoire Cachet a écrit :
> 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.

Ok mais comment faire pour que le module de stats puisse sortir quelquechose 
lui ?

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

Ok, je comprend mieux ! Le must ce serait vraiment que les modules ne soit pas 
dépendant entre eux, par exemple pour que je puisse gérer un site uniquement 
composé d'articles avec des catégories, ou un wiki sans catégories, mais je 
ne sais pas si c'est réalisable car il faudrait déjà une certaine 
abstraction.

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

Oui en effet; je n'ai pas trop l'habitude de jouer avec ce genre 
d'organisation du code (manque d'expérience) donc je perd un peu le nord 
parfois :-)

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

Je sais pas. Si on associe "admin" à la fonction "administration", ça casse 
toute l'abstraction. Donc le mieux selon moi ce serait de balader deux 
tableaux associatifs, un pour les différentes sections et un autre pour les 
paramÚtres.

Array (
	[0] => "admin",
	[1] => "stats"
)

Array (
	[param1] => "value1",
	[param2] => "value2"
)

A défaut de deux tableaux bruts on pourrait définir un objet contenant ces 
deux propriétés, et éventuelement des méthodes pour y accéder ...

Des requêtes plus explicites pourraient être utilisées à l'intérieur des 
modules bien sûr. Par exemple générer la requête à partir des informations 
ci-dessus pour récupérer le bon article, à l'intérieur du module gérant les 
articles...

La contrepartie c'est qu'avec cette méthode, tous les modules devront 
s'initialiser les uns aprÚs les autres pour voir s'ils ont besoins de se 
lancer d'aprÚs la requête interne. Ça pose un problÚme de performances, et 
c'est par là que j'en étais arrivé a la création d'un nouvel évenement lié à 
l'uri... mais ça cassait aussi l'abstraction. Pourquoi alors ne pas gérer des 
évenements en fonction de la requête interne standard tiens ?

-- 
Olivier Pascal