Bon, désolé mais j'ai encore un petit pb avec la gestion des paramètres :

Parmis les 11 paramètres du plugin, j'en ai un nommé "punbb_status" qui définit si la fonction d'enregistrement automatique des utilisateurs dans punbb via l'inscription de PWG est active. Ce paramètre peut prendre la valeur true (fonction active) ou false (fonction inactive) mais ce n'est pas un paramètre de type booléen.

Or, le champ des valeurs dans la table #_config est un champ de type texte. Lorsque le plugin est installé, il y a bien création de l'entrée "punbb_status" avec la valeur "false" par défaut et le commentaire associé. Mais il n'y a pas de remontée de cette information dans mon formulaire de  l'interface d'administration du plugin.

Pourtant tous les autres paramètres de mon plugin sont correctement remontés. Plus étrange, lorsque je modifie la valeur à "true" sur "punbb_status" via le formulaire d'administration, la modification est bien répercutée en base de donnée mais toujours pas affichée dans mon formulaire.

Est-ce parce que les valeurs de ce paramètre sont de type booléen (même si les données sont stockées dans un champ de type texte) ? Dans ce cas, comment faire ? Car une checkbox retournant une "vrai" valeur booléenne ne s'enregistre pas dans la table avec un typage de champ à "text". J'ai un message d'erreur SQL très furtif et impossible à recopier. Mais pour le coup, cette fois, je n'ai ni affichage de la donnée ni mise à jour en BDD.

Voici la requête d'installation du plugin concernant ce paramètre :

INSERT INTO '.CONFIG_TABLE.' (param,value,comment)
  VALUES
  ("punbb_status","true","Activation of Register_PunBB plugin");';

Un extrait de la fonction de mise à jour de la table #_config :

// Load configuration settings from database
load_conf_from_db('param like \'punbb\\_%\'');

// Update configuration settings in database
if ( isset($_POST['submit']) )
{
  $query = '
UPDATE '.CONFIG_TABLE.'
  SET value="'.$_POST['punbb_status'].'"
  WHERE param="punbb_status"
  LIMIT 1';
  pwg_query($query);

  $query = '
UPDATE '.CONFIG_TABLE.'
  SET value="'.$_POST['punbb_prefix'].'"
  WHERE param="punbb_prefix"
  LIMIT 1';
  pwg_query($query);
  
(...)

// Reload settings for correct display after update
load_conf_from_db('param like \'punbb\\_%\'');
}

Et le début de mon template d'admin pour le plugin :

<form method="post" action="{RegPunBB_F_ACTION}" class="general">
<fieldset>
  <legend>{lang:SubTitle}</legend>
<ul>
<li><label>{lang:PluginActivation}</label><br />
  <div align="center"><label><input type="text" name="punbb_status" value="{PUNBB_STATUS}" size="1" style="text-align: center;"/></label></div>
  <br /><br />
</li>
<li><label>{lang:Punbb_Prefix}</label><br />
  <div align="center"><label><input type="text" name="punbb_prefix" value="{PUNBB_PREFIX}" size="8" style="text-align: center;"/></label></div>
  <br /><br />
</li>
<li><label>{lang:Punbb_Default_Group}</label><br /><br />
  <div align="center"><label><input type="text" name="punbb_id_default_group" value="{PUNBB_ID_DEFAULT_GROUP}" size="1" style="text-align: center;"/></label></div>
  <br /><br />
</li>

[edit]
[HS]
rub : j'ai vu que tu t'étais inscrit sur ma galerie. C'est sympa, merci ! Pour info, tu est le 337ème membre depuis que PWG agrémente mon site.
[/HS]
[/edit]

Dernière modification par Eric (2007-05-13 03:16:44)

Philippe,

Je crois comprendre ton propos.
Je pense que ton analyse n'est pas exacte.

Mon plugin crée une ligne dans la table de configuration qui abouti à générer une $conf['ccccccccccc']
En quoi, cette variable nouvelle mettrait en péril nos galeries.
Le code de base de PhpWebGallery l'ignorera.

Maintenant deux risques:
- Ecrasement/Perte de la table par une procédure d'instal douteuse.
- Conflit de paramètre (écrase une valeur de conf officielle ou d'un autre plugin)

L'un comme l'autre, je préconise une table différente mais commune aux plugins, et à terme des
routines de création/modification/supression des $conf par PhpWebGallery.

Inconvénient: Une conf actuelle ne serait pas protégée pour autant par un plugin mal écrit.

Table(s) spécifique(s) => Axe de développement inutile à mon avis.
Par contre, le plugin à terme inclus dans PhpWebGallery: No doubt !!!

Eric, Rub: Vos avis seront décisifs.

8-)

VDigital a écrit:

L'un comme l'autre, je préconise une table différente mais commune aux plugins, et à terme des
routines de création/modification/supression des $conf par PhpWebGallery.

Pourquoi réinventer la poudre ? PWG propose une table de conf en natif. Il serait dommage de ne pas optimiser son emploi. D'autant plus que le risque de tout supprimer dans cette table est tout de même très minime.

Créer des Mods ou des plugins (car le cas peu également se présenter pour un Mod qui créerait des valeurs de conf dans #_config) n'est pas donné au premier venu - [ J'en sais quelques chose (sic) :-/ ] - et le developpeur est quand même sensé tester sont travail avant de le diffuser.

Personnellement, je me mets à la création de Mods / Plugins par besoin personnel. Si une erreur de ma part me déglingue toute ma galerie, je serai le premier impacté par la bévue et je ferai le maximum pour récupérer le coup avant même la diffusion du produit fini.

Non, franchement, la table #_config me convient très bien. Par contre +1 pour les routines de création/modification/suppression.

rub a écrit:

Sachant que la table #_conf est lu entièrement à chaque fois.

Je pense que cela étaye mes propos ci-dessus. Et enfonce le clou : La table #_conf est lue par défaut par PWG => Un souci en moins à gérer pour les plugins. Pour moi, les fonctions existantes du "noyau" de PWG doivent être exploitées avant d'éventuellement penser à en créer d'autres.

C'est un peu comme une loi votée mais non appliquée à laquelle on ajoute une seconde loi qui, elle sera appliquée ou fera appliquer la première.

Enfin, c'est ma vue du sujet.

rub a écrit:

Donc pour résumé, je suis pour:
  o une nouvelle table de configuration dédié aux plugins
  o une librairie de gestion de ces paramètres de configuration

Dixit ci-dessus, une nouvelle table serait inutile à mon sens. Mais, dans le cas proposé par rub, la nouvelle table devra être lu à chaque fois de la même manière que la table #_conf.

Et toujours +1 pour les fonctions de gestion des paramètres.

rub a écrit:

PS: Eric, je n'ai pas le temps de voir en détail ce que tu as fait mais tu dois peut-être convertir ton boolean en texte pour l'insertion (il y a une fonction pour)

Effectivement, je vais voir dans ce sens. Merci !

flipflip a écrit:

Autre soucis, pour les mises à jours. La structure de mes champs a changé et il peut arriver que la commande MySQL ALTER ne soit pas dispo pour un utilisateur (déjà rencontré :( ) donc pas de mise à jour possible. Alors qu'avec une table supplémentraire il est facile de supprimer la première table en stockant les données éventuellement d'une façon ou d'une autre, de créer la nouvelle table, faire les traitements pour faire correspondre les données au nouveau shéma et ensuite les reimporter. Bon après j'suis pas un expert en procédure de mise à jour, je pense que Pierrick pourrait nous éclairer la dessus (il me semble que c'est lui qui écrit les procédures de mise à jour pour PhpWebGallery ?).

Si dans #_conf, tu serialises, pas d'alter, juste un update => ça marche forcément!
ALTER sert à modifier une table, ça  n'arrive pas tous les jours, et ça fait partie desmanips à risque.

Si on pose:
le paramètre z du plugin A s'appelle A_z , alors je pense que tout se passera bien: pas de risque d'écrasement (sauf à avoir 2 plugins qui s'appellent pareil...)
Tout dans la table config. Les champs sont du texte, je ne vois pas ce qui pourrait empêcher PWG de lire la table, même avec des données pourrites.
Par contre, +10 000 pour les fonctions de Gestion des paramètres.

PS: Et si les plugins, c'étaient des greffons ;-). Ça pourrait être des modules, mais c'est proche de MODs et la confusion est possible pour les néophytes.

Eric a écrit:

[edit]
[HS]
rub : j'ai vu que tu t'étais inscrit sur ma galerie. C'est sympa, merci ! Pour info, tu est le 337ème membre depuis que PWG agrémente mon site.
[/HS]
[/edit]

Reste plus qu'à inscrire à ma démo ;-)

Eric a écrit:

Dixit ci-dessus, une nouvelle table serait inutile à mon sens. Mais, dans le cas proposé par rub, la nouvelle table devra être lu à chaque fois de la même manière que la table #_conf.

Dans ce cas, avec la librairie de fonctions ca ne sert à rien de faire une nouvelle table!
Si je pense qu'il faut justement ne pas faire de lecture à chaque, c'est que j'ai peur, que plein de données soient ramenées alors que ce n'est pas nécessaire.

Exemple: Prenons un plugin qui comme le pluginb-éta PhpMyVistes ajoute un bas de page, on va devoir sauvegarder du code HTML comme une paramètre classique de plugin (pour éviter de faire une table ou autre chose pour rien de plus).
Pour peu que tu essaies plusieurs plugin que tu installes, actives, désactives... A la fin, tu vas lire plein de codes HTML qui ne servent pas!
(je sais pas si c'est très clair comme exemple?)

flipflip a écrit:

Comme j'avais du l'écrire dans ce post ou un autre, je pense qu'il faudrait fournir une petite librairie de fonctions pour faire les lectures/miseAjour/écriture suppression.
Comme ca, d'une part, on peut mettre ce que l'on veut derrière (table #_conf ou #_config_plugin).

Tu veux dire qu'un dev pourra choisir quelle table il veut utiliser ?

Non.
C'est PWG qui gére le choix du stockage pas le développeur pour qui ca doit être "transparent".
Ce que je veux dire par ma phase, c'était que la table pourrait évoluer (historisation, date d'effet ou je-ne-sais-pas) sans incidence pour le dev du plugin.

flipflip a écrit:

Mon plugin crée une ligne dans la table de configuration qui abouti à générer une $conf['ccccccccccc']
En quoi, cette variable nouvelle mettrait en péril nos galeries.

C'est exacte dans le cas ou les procédures d'installation, désintallation, mise à jour sont correctement pensé et qu'elles n'ont pas généré d'erreur. Mais si par exemple pour une obscure raison l'une des procédure ce passe mal et écrit un peu tout et n'importe quoi dans la table _config, PhpWebGallery ne pourra pas ce passer de ces paramètres pour fonctionner. Alors vous allez me dire, c'est au dev de faire correctement sont taf. Mais je vois tellement des trucs bizarre en info (dev ou réseau) que je préfère prendre le minimum de risque. La création d'une table par plugin permet d'éliminer le risque d'erreur d'écriture dans _config.

+1

mathiasm a écrit:

Si on pose:
le paramètre z du plugin A s'appelle A_z , alors je pense que tout se passera bien: pas de risque d'écrasement (sauf à avoir 2 plugins qui s'appellent pareil...)
Tout dans la table config. Les champs sont du texte, je ne vois pas ce qui pourrait empêcher PWG de lire la table, même avec des données pourrites.
Par contre, +10 000 pour les fonctions de Gestion des paramètres.

(mathiasm qui ecrit pourrite? T'es pas de tch'nord pourtant ;-))

Ce n'est pas empêcher de lire mais simplement de ramener trop de données. (cf mon exemple au dessus)

Ce que je vous propose de faire:

Etape 1:
  o Mise en place de la librairie avec les fonctions de lecture/ecriture/création/suppression de paramètres
  o Chacune des fonctions auront une argument identique, le nom court du plugin
  o Tous les paramètres seront sauvegardés dans un seule ligne (serialize) de la #_config avec comme id "plugin_<pluginname>"
  o L'accés aux valeurs se fera de la façon suivante:
      $conf[<pluginname>][<value_name>]
    et après que la fonction de lecture ai été appliquée
  o La librairie pourra être intégrée dans les plugins en cours (si la fonction qui-va-bien n'existe pas, j'inclus le fichier librairie php qui va bien)
  o Intégration de la librairie pour la version 1.7.1 (=> des la passage en 1.7.1, vu que la fonction qui-va-bien existera bien, le librairie  fichier php qui va bien ne sera plus inclus)

Etape 2:
  o Integration en 1.7.1
  o Les plugins ne seront plus obligés d'inclure la librairie sauf pour garder une compatibilité avec la 1.7.0

Etape 3:
  o en 1.8
  o Pourquoi pas une table #_config_plugin! Dans ce cas, les données ne seront plus sauvegardés dans une ligne mais sur plusieurs
  o Migration des données plugin
  o Pas de changement à faire dans les plugins

mathiasm a écrit:

rub a écrit:

Ce que je vous propose de faire:

Etape 1:
  o Tous les paramètres seront sauvegardés dans un seule ligne (serialize) de la #_config avec comme id "plugin_<pluginname>"

Quelle est la taile maximale du champ valeur? C'est la seule limite que je vois pour l'instant...

C'est un type "text" donc pas de limite (ou presque).

mathiasm a écrit:

rub a écrit:

Etape 3:
  o en 1.8
  o Pourquoi pas une table #_config_plugin! Dans ce cas, les données ne seront plus sauvegardés dans une ligne mais sur plusieurs
  o Migration des données plugin
  o Pas de changement à faire dans les plugins

Si ça marche réellement à l'étape 1, pourquoi changer ? On économise une table à lire à chaque page.

Pour les raisons ce-dessus, la pollution de la table #_conf, les lectures inutiles et le fait de bien séparés les paramètres internes et externes.

De plus en s'arrangeant bien si le nom du plugin passé en paramètre est implicite (nom du plugin en fait), la lecture de l'ensemble des paramètres nécessaires au plugin se fera en une seule fois!