🌍
Français
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.
VDigital a écrit:
Tu as compris ce que j'imaginais, c'est l'essentiel...
Arrange à ta sauce, c'est nickel.
Houlala, j'en suis pas la.
Je finis d'abord mes plugins PhpMyVisites et Dotclear (pour les liens à insérer) et la librairie... ensuite, on verra... ;-)
Tu as compris ce que j'imaginais, c'est l'essentiel...
Arrange à ta sauce, c'est nickel.
8-)
VDigital a écrit:
De toute façon copie de l'ancien en config_local.inc.#TIMESTAMP#.bak
Non?
En fait, je pensais plus à une table d'historiques, car il faudrait pouvoir modifier l'ensemble des fichiers "local" (config php, lang php, css, ...).
Dans une table, ca permettrai de restaurer une version supprimée ou écrasée.
"Historiser" dans une table, 2 façons par exemple:
o nouvelle table dédiée
o utilisation de la table #_conf et du futur nouveau champs #config.auto_load à false
De toute façon copie de l'ancien en config_local.inc.#TIMESTAMP#.bak
Non?
Purge et restructuration du fichier en gros!
Garder un historique pourrait être sympathique aussi!
L'objectif aussi de pouvoir au final proposer l'écriture et d'éliminer les espaces et les lignes vierges après le ?>
8-)
rub a écrit:
D'ailleurs, je mettais dit aussi qu'un plugin permettant de mettre à jour le fichier config_local.inc.php pourrait être sympa!
Je pensais aussi à une idée de ce genre.
Idée qui consisterait à redonner le contenu nécessaire strictement de config_local.inc.php.
Soit en gros:
Unset de $conf
@include de config_local
copie de $conf dans $prev
@include de config_default
Toute valeur de $prev (= à celle de $conf) => unset de la $prev.
Unset de $conf
$conf=$prev
plugin.CONF => var_dump($conf)
reload de $conf
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!
rub a écrit:
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!)
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?).
A+
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.
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 ....)
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!)
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 ;-)
Ce que je souhaiterais qu'on évite c'est de faire une requête par paramètre. En dehors de cette "crainte", je pense que toute amélioration n'est pas néfaste :-)