VDigital a écrit:
Sans doute, mais un fichier pem_metadata.php, je n'ai pas vu de réponse de P@t sur ce point.
Ben, c'est ta faute ;-)
Je pensais que tu avais transcrit le résultat du commit de P@t...
P@t a parlé de pem_metadata.txt...
Mais, peu importe le type de fichier, la logique est la même...
Par contre le type de fichier (txt, php, xml, ...) influera sur la façon de lire les données ainsi que sur accessibilité des valeurs.
Mieux vaut les cacher de tous... donc, je rejoins VDigital serait le mieux...
Hors ligne
En effet, il faudrait uniformiser ce fichier pour qu'il soit commun à tous les types d'extension (plugins, templates, themes...)
Perso, je préfèrerais un fichier .txt, c'est beaucoup plus facile à modifier par PEM avec un preg_replace.
Il n'y a pas grand interet à ce qu'ils soient cachés.
Pour les descriptions multilingues, j'aurai plutot vu un fichier description.txt dans le dossier de chaque langue.
Un peu comme le fichier iso.txt. Qu'en pensez-vous?
Hors ligne
P@t a écrit:
Perso, je préfèrerais un fichier .txt, c'est beaucoup plus facile à modifier par PEM avec un preg_replace.
que veux tu remplacer ?
- la version qui sera automatique ? si oui tu n'as qu'a adapter le code d'avant pour main.inc.php pour ext_info.php
- autre Pk ?
sinon la description comme vous voulez, ca m'importe peu
Dernière modification par flop25 (2009-07-17 15:04:46)
Hors ligne
flop25 a écrit:
P@t a écrit:
Perso, je préfèrerais un fichier .txt, c'est beaucoup plus facile à modifier par PEM avec un preg_replace.
que veux tu remplacer ?
- la version qui sera automatique ? si oui tu n'as qu'a adapter le code d'avant pour main.inc.php pour ext_info.php
Dans l'absolu, oui... mais il y a moins de risques d'erreur avec un fichier txt tout simple.
Imaginons que mon ext_info.php se présente ainsi:
$plugin[' Name'] =
'test';
$plugin['Version'] =
"x.X.xy;
$plugin['Description'] = array(
['default'] = '....',
['fr-FR'] = '....',
);
C'est tout de suite un peu plus embetant à modifier...
Hors ligne
Pourquoi remplacer?
Le fichier txt ne pourrait pas être généré automatique et entièrement par PEM?
Si on fait un txt autant faire un xml, non?
+0.5 pour le fichier description.txt dans chaque répertoire de langue
0.5 car je préfectures un fichier ext.??? afin de gérer autre que les descriptions...
Hors ligne
si tu pars sur .txt, je ne change pas mon système de maj actuel
et ainsi toutes les extensions unifiées par un P@t en grande forme vont pouvoir être mise à jour automatiquement - je rêve debout heu assis ? - . Dans ce cas il faudrait ajouter un ext['type'] ou un ext['chemin'] où extraire le zip. Et le nouvel updater cherchera dans les chmein courant des extensions les fichiers ext_info.txt
Dernière modification par flop25 (2009-07-17 15:18:32)
Hors ligne
rub a écrit:
Pourquoi remplacer?
Le fichier txt ne pourrait pas être généré automatique et entièrement par PEM?
Si on fait un txt autant faire un xml, non?
+0.5 pour le fichier description.txt dans chaque répertoire de langue
0.5 car je préfectures un fichier ext.??? afin de gérer autre que les descriptions...
je pense que l'on devrait clarifier nos besoins afin de prendre les bons choix !
Hors ligne
J'ai rien contre le xml, mais comment on génère du xml?
Ca m'embete de devoir faire un fichier xml pour mes plugins...
En premier choix, je suis pour un txt, et en deuxième choix un php.
Pour les descriptions, je proposais ca car c'est plus logique de mettre ca dans le dossier language.
Et ca sera bien plus pratique pour les traducteurs de repérer ce fichier...
Et ca n'empeche pas d'avoir aussi un autre fichier pour la version, l'auteur, etc...
Bon, en tout cas, la discussion est lancée ;-)))
Dernière modification par P@t (2009-07-17 15:32:46)
Hors ligne
P@t a écrit:
J'ai rien contre le xml, mais comment on génère du xml?
A la minine comme les sites distants... mais en tout cas en php5, la lecture est simplifié car les functions sont présentes... Et pour la génération, ca doit être pareil...
P@t a écrit:
Ca m'embete de devoir faire un fichier xml pour mes plugins...
Ben, en tant que plugeur, tu t'en fiches si c'est gérer automatique par PEM... non?
P@t a écrit:
En premier choix, je suis pour un txt, et en deuxième choix un php.
Peu importe, pour moi, ca dépend surtout du fait si on veut les informations soient accésibles par tous...
On cache bien la version de Piwigo...
Si le plugin A a une faille, il suffit de lire le fichier txt pour savoir qu'il peut utiliser la faille...
P@t a écrit:
Pour les descriptions, je proposais ca car c'est plus logique de mettre ca dans le dossier language.
Et ca sera bien plus pratique pour les traducteurs de repérer ce fichier...
Et ca n'empeche pas d'avoir aussi un autre fichier pour la version, l'auteur, etc...
Mais, trop de fichiers ca risque d'alourdir le truc, non? Surtout pour traducteurs...
En tout cas, +1 pour un ou des fichiers dans chaque répertoire de langue...
P@t a écrit:
Bon, en tout cas, la discussion est lancée ;-)))
yes...
Je vais reformuler mon besoin...
Je veux pouvoir:
o gérer mes informations multilingues
o avoir mes versions automatiques
o avoir au niveau de ma galerie l'information de révision svn
o pourvoir ajouter d'autres infos
o que ca soit pour un plugin, un théme, une extension
uniquement en basant que ce je saisis ou j'utilise dans PEM...
Hors ligne
rub a écrit:
P@t a écrit:
En premier choix, je suis pour un txt, et en deuxième choix un php.
Peu importe, pour moi, ca dépend surtout du fait si on veut les informations soient accésibles par tous...
On cache bien la version de Piwigo...
Si le plugin A a une faille, il suffit de lire le fichier txt pour savoir qu'il peut utiliser la faille...
Avec un fichier xml, c'est la même chose.
Si tu veux bien le faire en php. Ton php, peux le lire ou l'inclure, mais un site externe ne pourra pas voir son contenu et déterminer si faille il y a ou pas.
Mais je vous laisse cogiter.
;-)
Hors ligne
rub a écrit:
Je veux pouvoir:
o gérer mes informations multilingues
o avoir mes versions automatiques
o avoir au niveau de ma galerie l'information de révision svn
o pourvoir ajouter d'autres infos
o que ca soit pour un plugin, un théme, une extension
uniquement en basant que ce je saisis ou j'utilise dans PEM...
avoir au niveau de ma galerie l'information de révision svn???
Ca n'interesse que l'auteur du plugin cette info, et encore!
Aucun interet pour un webmaster...
Pour le reste, c'est ok ;-)
PS: je vais oucrir un nouveau topic...
Dernière modification par P@t (2009-07-17 18:07:57)
Hors ligne
P@t a écrit:
Ca n'interesse que l'auteur du plugin cette info, et encore!
Aucun interet pour un webmaster...
Dans ce cas, il faut avoir l'info dans PEM pour faire le lien version/révision...
Le plus simple serait comme version la révision...
Hors ligne
VDigital a écrit:
rub a écrit:
P@t a écrit:
En premier choix, je suis pour un txt, et en deuxième choix un php.
Peu importe, pour moi, ca dépend surtout du fait si on veut les informations soient accésibles par tous...
On cache bien la version de Piwigo...
Si le plugin A a une faille, il suffit de lire le fichier txt pour savoir qu'il peut utiliser la faille...Avec un fichier xml, c'est la même chose.
Si tu veux bien le faire en php. Ton php, peux le lire ou l'inclure, mais un site externe ne pourra pas voir son contenu et déterminer si faille il y a ou pas.
Mais je vous laisse cogiter.
;-)
On n'a jamais dit que c'était pas la même chose, bien au contraire...
=> pas besoin de cogiter... ca fait 36 posts qu'on le dit...
Hors ligne
rub a écrit:
P@t a écrit:
Ca n'interesse que l'auteur du plugin cette info, et encore!
Aucun interet pour un webmaster...Dans ce cas, il faut avoir l'info dans PEM pour faire le lien version/révision...
Le plus simple serait comme version la révision...
je ne suis pas pour ou alors le lien est 'caché' : l'utilisateur lambda n'est pas habitué à voir des R5478 mais des 2.0.5
'déterminer si faille il y a ou pas.' à quoi penses tu Vd : si le php renvoie une erreur, on ne peut pas lire le fichier donc c'est un inconvénient ?
si on part sur un xml autant créer depuis pem une liste rss ou assimilé en xml : moins d'accès serveurs car on ne fait de requête php
Hors ligne
j'ai réfléchit et il est vrai que le xml a de nombreux avantage et est très facile à utiliser (en fait je ne me souvenait plus que j'en manipulait dans music_player) surtout si on fait nos propres balise type :
<ext_info>
___<name></name>
___<type></type>
___<version></version>...
</ext_info>
<ext_description>
__<fr></fr>....
on en est où alors de l'idée ?
Hors ligne