rvelices a écrit:

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

Bonne idée, ca sera pour l'étape 3 par contre.


Par contre, je me disais aussi qu'il ne sera pas possible de mettre à jour les valeurs avec le config_local.php.
Car $conf[plugin_<plugin_name>][<param_name>], c'est peut-être un peu compliqué et avec le serialize, ce n'est pas possible.

Donc, je pensais rajouter dans l'administration, un fenêtre générique permettant de mettre à jour les paramètres des différents plugins (point d'entrée global et/ou dans la liste des plugins). Chaque développeur dans son plugin pouvant interdire cette mise à jour (par exemple, si son plugin fournit déjà les interfaces de mises à jour qui vont bien!)

rvelices a écrit:

rub a écrit:

Donc, je pensais rajouter dans l'administration, un fenêtre générique permettant de mettre à jour les paramètres des différents plugins (point d'entrée global et/ou dans la liste des plugins). Chaque développeur dans son plugin pouvant interdire cette mise à jour (par exemple, si son plugin fournit déjà les interfaces de mises à jour qui vont bien!)

Le probleme c'est que tu ne peux faire absolument aucune validation sur le parametre (entier positif, boolean, etc ....)

Effectivement, on peut seulement faire des contrôles sur le type (chaine, booléen, numérique).
On peut même pousser le truc pour gérer les tableaux.

Mais, c'est vrai pas de test sur entier position, entier compris entre x et y.
On pourrait implémenter qqchose pour gérer ca, mais ca serait trop compliqué, pas beau, pas nécessaire.

En fait, cette fenêtre aurait le même usage que le config_local.php avec les même contraintes, le mieux pour un plugin étant que ca soit lui qui gère ses paramètres.

mathiasm a écrit:

(Ça ressemble à un template d'administration, non?)

Un peu, je dirais plus une page générique.

En tout cas, on verra ce que ca donnera, mais le système pourrai éventuellement être adapté à nos fichiers config_*.inc.php pour faciliter la mise à jour.
D'ailleurs, je mettais dit aussi qu'un plugin permettant de mettre à jour le fichier config_local.inc.php pourrait être sympa!

L'objectif aussi de pouvoir au final proposer l'écriture et d'éliminer les espaces et les lignes vierges après le ?>

8-)

De toute façon copie de l'ancien en config_local.inc.#TIMESTAMP#.bak
Non?

Tu as compris ce que j'imaginais, c'est l'essentiel...
Arrange à ta sauce, c'est nickel.
8-)

Désolé pour ce moment d'absence, je suis tombé en rade de net depuis dimanche :(
Donc je reprend à cette discution http://forum.phpwebgallery.net/viewtopi … 077#p60077 .
Les seuls moment où je vois le besoin d'utiliser ALTER est pour l'ajout d'un champ et ça suppression (qui soit serialisé ou pas). Donc risque de mauvaise manipulation, erreur d'exécution et donc plantage de la table _config.

Eric a écrit:

- des *données* de paramétrage d'un plugin à stocker = pas de danger réel.
- des *informations* de fonctionnement d'un plugin = danger !

Parfaitement d'accord, les données nécessaires au fonctionnement du plugin (donc pas les paramètres du plugin) doivent eux avoir leur propre table.

rub a écrit:

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

hummmm appétisant ce programme :)

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

La seule limite que je vois est les performances du serveur, plus le champs sera long et plus il demandera de ressource pour le lire et le stocker.

VDigital a écrit:

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

Plus un pour une table séparé, si le plugin est désactivé, supprimé ça table n'est pas lu.

rub a écrit:

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

Non non il faut une librairie pour avoir un mode de fonctionnement et de création des plugins identique de façon à gagner en temps et ne pas reinventer la roue à chaque fois.

mathiasm a écrit:

Pour moi, on doit fournir une interface pour gérer les paramètres, surtout si on fournit la biblio de fonctions.
Comme ça, le dev qui n'est pas accro au HTML peut quand même fournir qqch de correct (Ça ressemble à un template d'administration, non?).

Euuu un mec qui dev en php est, il me semble, capable de contruire une interface html, avec 3 champs ? :)

Pour l'aspect dev je fais entièrement confiance à l'équipe, jusqu'a présent je n'ai jamais eu de mauvaise surprise ;)
Au contraire je joue toujours le parano de service concernant le stockage de la configuration des plugins.