fil-JM9gtpQu/Ho@public.gmane.org wrote:
Author: fil-JM9gtpQu/Ho@public.gmane.org
Date: Thu May 3 01:08:53 2007
New Revision: 11812Log:
je hacke a fond pour assurer la securite et un affichage sympa...
> il vaudrait mieux que je m'abstienne, toggg
Ah, ça serait dommage pour un gogo 
Je ne sais trop quoi dire mais il est clair que ce truc commence à me déplaire aussi, pour quelque chose qui se voudrait moderne il y a beaucoup trop de html intégeé dans le php. Je voudrais bien que tout passe par des, ou plutôt *le*, modèle. Je dit *le* car je ne pense pas qu'il soit souhaitable de multiplier les recuperer_fond().
Déjà, si je comprends ton hack, tu aurais besoin de faire passer au fond des paramètres supplémentaires (hors champs) et pour cela exécuter une certaine dose de php.
J'avais envisagé à l'époque de fournir une propriété genre
[(#REM) include_php=inc/cfg_autorite.php]
qui permettrait de faire appel à du php custom.
Mais ce ne serait pas très satisfaisant, car comment récupérer et intégrer ce que ce php ferait ?
Il serait dommage de ne pas profiter du mécanisme objet de cfg, en théorie on peut étendre la classe utilisée, cf. function exec_cfg_dist()
Et là, si on passe par ce genre de propriété, c'est déjà trop tard car l'objet est déjà créé.
Ce que je me propose de faire:
Avant d'instancier l'objet cfg, inclure si il existe un truc comme inc/cfg_machin.php ou plutôt fonds/cfg_machin.php pour garder les sources cote à cote
Dans ce php, tu définis ta classe cfg qui étend cfg_dist.
Par exemple, fonds/cfg_autorite.php contiendrait:
<?php
class cfg extends cfg_dist
{
var $propriete_en_plus = ...
function cfg($nom, $vue = '', $cfg_id = '', $opt = array())
{
... des trucs spécifiques ...
parent::cfg_dist($nom, $vue, $cfg_id, $opt)
... des trucs spécifiques post instanciation
}
// passer des éléments supplémentaires à recuperer_fond
function get_fond($contexte = array())
{
$contexte['env_sup'] = ...;
...
return parent::get_fond($contexte);
}
// cfg_dist fournirait une methode autoriser() {return true;}
// si pas bon ==> un minipres() + exit
// ici, tu peux la redéfinir
function autoriser()
{
// evaluer si tu autorises ce cfg
if (bla bla) {
// ou return true; mais autant réserver le futur
return parent::autoriser();
}
return false;
}
// autres methodes redefinies
...
}
?>
Ça me semble assez élégant ... on pourrait aussi redéfinir carrément sortie(), debut_page() ... etc.
Eventuellement, ça peut poser un problème si on a plusieurs cfg de natures différentes sur la même page, mais on pourra implanter facilement un mécanisme pour permettre plusieurs redéfinitions avec des noms de classe différents quand cfg sera complètement éclaté et plus seulement un exec ... on verra.
Par ailleurs, pour la demande de Nicolas, je vais implanter un methode log() qui fera essentiellement un spip_log() des valeurs anciennes/nouvelles en cas de modification. (aussi redéfinissable, bien sûr)
Enfin, je vais rapidement enlever le sabot, il semble que la séparation du storage ne pose pas de problème ... pour l'instant. Par exemple "classic" pourrait permettre de refaire les panneaux de configuration actuels.
--
toggg