Re: Test du nouveau type d'évenemen t

Olivier Pascal wrote:
> 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.

Bof, les catégories si tu n'en veux pas il suffit de ne pas t'en servir. 
Et un wiki c'est juste un blog sans index par date et où tout le monde 
peut écrire finalement (vu que nos URL sont dors et déjà adaptées)

Bref, l'abstraction est déjà là. Ce qu'on a c'est un moteur de gestion 
de document. Ce que ça donne dans l'esprit utilisateur ça va fortement 
dépendre de l'apparence que tu as (si tu fais un index par date, si tu 
met des liens vers l'édition sur toutes les pages ...)

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

Module :)

Pour gérer ça tu fais un module qui prend la main en premier, regarde si 
la catégorie s'appelle "stats" et crée une requête interne spéciale pour 
ce type d'URL. Lors des traitements c'est pareil tu as un gestionnaire 
qui prendra la main juste avant le gestionnaire par défaut et qui 
lancera les actions de stat/admin pour avoir le contenu au lieu d'aller 
le chercher dans la base.

Pas besoin pour ça d'avoir un "plan" du site organisé en sections.


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

C'est le problÚme que j'avais soulevé il y a quelques jours : on va 
charger chaque gestionnaire et potentiellement exécuter seulement un "if 
(! on_est_en_section_admin ) return" en ayant compilé/chargé plein de 
code pour rien.

Pour l'instant je vous suggÚre de laisser tel quel et de ne pas vous en 
préoccuper. Quand on aura un truc qui marche, vu qu'on a une phase de 
génération on peut tout à fait se permettre de "construire" le code PHP 
du constructeur et mettre la condition directement dedans. On aurait 
donc à la place un code dans le constructeur qui dit "if 
(on_est_en_section_admin) charge_le_gestionnaire_X". Si la condition 
n'est pas validée on ne charge pas le gestionnaire pour rien et on ne 
perd rien en performance (à part peut être quelques test "if" mais ça 
c'est nettement négligeable).
C'est ça que j'entendais par "fonction inline". Ce n'est techniquement 
pas trop complexe à gérer, mais à mon avis il vaut mieux se concentrer 
sur le reste d'abord, ça c'est de l'ajout.

-- 
Eric