Les anciens plugins qui n'effaceraient pas leurs traces en table config.
ou
Cas de perte du contenu du répertoire plugins.

Comment cela sera géré?

(discussion fort intéressante, merci à mathiasm de m'avoir demandé mon avis par email)

Mon avis sur la question: je suis très très favorable à l'écriture d'une petite bibliothèque de fonctions permettant la lecture/écriture/suppression de paramètres. Ce qui dans mon esprit donnerait:

// echo '<pre>'; print_r($conf); echo '</pre>';
//
// Array
// (
//     [history_guest] => 1
//     [log] => 1
//     [plugin_admin_advices] => Array
//         (
//             [param1] => value1
//             [param2] => value2
//             [param3] => value3
//         )
//     [plugin_event_tracer] => Array
//         (
//             [param1] => value1
//         )
// )

set_plugin_conf(
  'admin_advices',
  array(
    'param1' => 'new_value1',
    'param2' => 'new_value2',
    )
  );

delete_plugin_conf_parameter('admin_advices', 'param3');
delete_plugin_conf('event_tracer');
reload_conf();

// echo '<pre>'; print_r($conf); echo '</pre>';
//
// Array
// (
//     [history_guest] => 1
//     [log] => 1
//     [plugin_admin_advices] => Array
//         (
//             [param1] => value1
//             [param2] => value2
//         )
// )

En ce qui concerne la façon de stocker dans la table #config, mon avis c'est que #config.param doit être plugin_<plugin_id>_<param_name>, par exemple plugin_admin_advices_param2. Pas de sérialization (la structure est déjà là, donc sérialisation inutile). A noter que quand je parle de plugin_id, je parle de #plugins.id.

rub a écrit:

Par contre, je préférais avoir un serialize pour les raisons suivantes:
  o [...]
  o ca évite de pouvoir modifier facilement les données sans passer par la librairie

Argh... t'es à deux doigts de vouloir faire du logiciel propriétaire là. C'est du discours de décideur commercial (excuses moi d'être aussi brutal ;-)

rub a écrit:

o vue que l'accés se fera par $[plugin_admin_advices][param1] si on fait une ligne par paramètre, on aura des $conf[plugin_admin_advices_param1] à remettre dans un tableau $conf[plugin_admin_advices] et les $conf[plugin_admin_advices_param1] à unset.
    => cad une organisation de $conf différente de la table #_config

Oui, tout à fait. Je milite en faveur d'une fonction load_conf qui bouclerait sur les paramètres un par un, pour les transformer en booléen et pour les ranger dans des sous-tableaux.

(Pour rappel, entre nous, dans les "searches" on fait quoi?)
Ceci dit, vos idées me plaisent bien.

("à deux doigts": on est encore à côté, non?).
8-)

VDigital a écrit:

(Pour rappel, entre nous, dans les "searches" on fait quoi?)

On doit sérialiser pour #search car on ne connait pas à l'avance le nombre de paramètres utilisés et ce serait dommage de devoir faire évoluer le modèle de #search si on ajoute un champ dans #images (qui peut potentiellemet être faire partie de la recherche)

Ce qui me gêne dans la sérialisation dans #config.value, c'est que c'est pour "mettre des bâtons" dans les roues. Je pense que si cet argument n'avait pas été mis en avant, j'aurais émis moins de réserve.

Note: dans le futur, utiliser de la sérialisation dans #config.value pourrait avoir du sens, pour des paramètres complexes que l'on souhaite gérer par écran (la frontière est fine avec un ensemble de paramètres pour un plugin).

z0rglub a écrit:

Ce qui me gêne dans la sérialisation dans #config.value, c'est que c'est pour "mettre des bâtons" dans les roues. Je pense que si cet argument n'avait pas été mis en avant, j'aurais émis moins de réserve.

Je n'ai jamais écrit ca, dans mon esprit c'est pour la sécurité et l'encapsulation des paramètres pas pour mettre des bâtons dans les roues mais au contraire pour aider les développeurs, je suis navré qu'on me comprenne ainsi.

Si tu relis le post depuis le début :

o ca évite de pouvoir modifier facilement les données sans passer par la librairie

ne veut pas dire que je veux faire quelque chose de propriétaire ou bien mettre des bâtons dans les roues.

MA CONCLUSION:
Dans ce cas, la librairie ne sert à rien, chacun gère comme il veut ses paramètres dans la table #_config.

Dernière modification par rub (2007-05-15 16:49:04)

J'ai pas trop participe,
mais serialise ou pas - ca peux toujours etre le choix du plugin s'il desire ... a lui de faire ...

Ce qu'il faudrait faire au minimum 3 fonctions du genre:
delete_param_from_conf_table
update_param_in_conf_table
insert_param_in_conf_table

je me demande s'il ne faudrait pas avoir une colonne #config.auto_load . Du genre j'ai un plugin avec beaucoup des donnnees, mais je l'utilise tres rarement donc il faudrait le charger seulement quand il y a besoin ...

z0rglub a écrit:

hop hop hop, pardon rub si je t'ai paru agressif. Ce n'était pas du tout l'objectif. Au contraire mon dernier post allait dans le sens: je te fais confiance pour faire de la bonne façon, sérialisation ou pas. La librairie de fonctions pour accéder au paramètres de configuration, c'est une très bonne chose.

Nos posts se sont quelque peu croisés!

z0rglub a écrit:

J'ai une expérience professionnelle qui m'a appris a parfois trop me "méfier" des tentatives de cacher certaines choses alors que ce n'est pas justifié. Par exemple, la table de configuration ne contenait aucun libellé, que des chiffres, c'était complètement illisible (et c'était partiellement fait exprès).

Je comprends ;-)