Pour faire court, j'ai un hash qui contient des données, que je voudrais
sauvegarder dans un fichier en xml (voire dans une bdd, mais ce sera
pour plus tard, une chose à la fois ;-)
Sauf que les choses ne sont pas si simples que cela ;-/
J'ai deux problèmes :
1. mes données peuvent changer dans mon hash (ie les clés, et par
conséquent les valeurs aussi, changent d'une exécution à l'autre).
Or, je souhaite ordonner les clés d'une certaine manière (que je
connais en fonction de certains paramètres contenus dans le hash
lui-même).
Je signale que les valeurs peuvent à leur tour être des hash (ou des
tableaux ou des scalaires).
2. au moment où je sauve mes données dans le fichier xml, je voudrais
"en mettre certaine en gras" (ok, ça n'a pas de sens en xml, mais je les
collerai juste dans une balise qui sera interprétée pour faire cela).
Comme ces données correpondent à des expressions régulières, je dois le
faire en perl.
Et à cause de ces 2 points, je ne sais pas trop comment faire pour créer
mon fichier.
J'ai bien une idée en tête, mais je ne sais pas si elle tient la route,
s'il n'y a pas plus simple, ...
En gros, je pensais "attacher" une méthode à chaque "clé" pour dumper la
valeur correspondante en xml, de la manière que je veux. Avant d'écrire
réellement dans le fichier, je passe mon texte dans un parser qui me
recherche les données "à mettre en gras".
Une meilleure idée ? Une manière simple de faire cela ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Paul Bert
In article <c1v1sj$uog$, Michel Rodriguez wrote:
Paul Bert wrote:
Pour faire court, j'ai un hash qui contient des données, que je voudrais sauvegarder dans un fichier en xml (voire dans une bdd, mais ce sera pour plus tard, une chose à la fois ;-)
La je comprends plus. Pourquoi ne pas sauter l'etape XML et directement utiliser un BD? Ca t'eviterais de faire 2 fois la meme chose. Prends DBI et DBD::SQLite par exemple, et tu perds d'un cote en lisibilite des donnees, mais tu gagne en vitesse, probablement en facilite de traitement (ca depend de la structure de tes donnees), et en possibilites d'evolutions futures (en remplacant SQLite par autre chose). La BD est contenues dans un fichier unique, et il n'y a pas d'admin a faire, brefle, le saut n'est pas si important de XML a une BD. Sinon YAML est pas mal non plus, plus lisible que XML a mon avis.
Le XML me sert uniquement àprésenter les résultats, pour qu'ils soient facilement "exportables" en html, pdf ou je ne sais quoi encore. La sauvegarde dans une bdd ne sera qu'une option, la présentation des résultats de l'exécution est le but du script.
Bref, je me dis, peut-être à tort (?), que c'est XML qui me permettra le plus facilement d'exporter mes résultats au(x) format(s) que je veux.
Mais bon, si tu insistes pour utiliser XML...
Ce que je fais dans les cas comme ca c'est avoir 2 (ou plus) passes: d'abord cree du XML, sans te preoccuper de l'ordre ni du gras. Essaye XML::Simple, XML::Dumper, Data::DumpXML (de tete, je me plante peut etre sur les noms des modules) ou des betes prints. Ensuite je reprends ca avec des outils XML, pour trier et rajouter le gras. C'est pas la seule methode, mais par experience ca correspond a 2 types de traitements assez differents pour meriter d'etre separes: passer de non-xml a du xml, et retravailler du xml avec des outils xml.
Effectivement, ça pourrait bien être plus simple que de tenter de faire les 2 en 1 ... mais ça ne résoud pas mon problème de "polymorphisme" (au sens premier du terme, cad que mes données peuvent être dans des structures différentes).
Mais vraiment, si tu manipules des donnees dont l'habitat naturel est une BD, ca me semble cruel de les transplanter dans du XML sans bonne raison. XML c'est un camion, ca sert a transporter des trucs, pas de residence principale. ;--)
:-)
Paul.
In article <c1v1sj$uog$1@news-reader1.wanadoo.fr>, Michel Rodriguez wrote:
Paul Bert wrote:
Pour faire court, j'ai un hash qui contient des données, que je voudrais
sauvegarder dans un fichier en xml (voire dans une bdd, mais ce sera
pour plus tard, une chose à la fois ;-)
La je comprends plus. Pourquoi ne pas sauter l'etape XML et directement
utiliser un BD? Ca t'eviterais de faire 2 fois la meme chose. Prends DBI
et DBD::SQLite par exemple, et tu perds d'un cote en lisibilite des
donnees, mais tu gagne en vitesse, probablement en facilite de
traitement (ca depend de la structure de tes donnees), et en
possibilites d'evolutions futures (en remplacant SQLite par autre
chose). La BD est contenues dans un fichier unique, et il n'y a pas
d'admin a faire, brefle, le saut n'est pas si important de XML a une BD.
Sinon YAML est pas mal non plus, plus lisible que XML a mon avis.
Le XML me sert uniquement àprésenter les résultats, pour qu'ils soient
facilement "exportables" en html, pdf ou je ne sais quoi encore. La
sauvegarde dans une bdd ne sera qu'une option, la présentation des
résultats de l'exécution est le but du script.
Bref, je me dis, peut-être à tort (?), que c'est XML qui me permettra le
plus facilement d'exporter mes résultats au(x) format(s) que je veux.
Mais bon, si tu insistes pour utiliser XML...
Ce que je fais dans les cas comme ca c'est avoir 2 (ou plus) passes:
d'abord cree du XML, sans te preoccuper de l'ordre ni du gras. Essaye
XML::Simple, XML::Dumper, Data::DumpXML (de tete, je me plante peut etre
sur les noms des modules) ou des betes prints. Ensuite je reprends ca
avec des outils XML, pour trier et rajouter le gras. C'est pas la seule
methode, mais par experience ca correspond a 2 types de traitements
assez differents pour meriter d'etre separes: passer de non-xml a du
xml, et retravailler du xml avec des outils xml.
Effectivement, ça pourrait bien être plus simple que de tenter de faire
les 2 en 1 ... mais ça ne résoud pas mon problème de "polymorphisme" (au
sens premier du terme, cad que mes données peuvent être dans des
structures différentes).
Mais vraiment, si tu manipules des donnees dont l'habitat naturel est
une BD, ca me semble cruel de les transplanter dans du XML sans bonne
raison. XML c'est un camion, ca sert a transporter des trucs, pas de
residence principale. ;--)
Pour faire court, j'ai un hash qui contient des données, que je voudrais sauvegarder dans un fichier en xml (voire dans une bdd, mais ce sera pour plus tard, une chose à la fois ;-)
La je comprends plus. Pourquoi ne pas sauter l'etape XML et directement utiliser un BD? Ca t'eviterais de faire 2 fois la meme chose. Prends DBI et DBD::SQLite par exemple, et tu perds d'un cote en lisibilite des donnees, mais tu gagne en vitesse, probablement en facilite de traitement (ca depend de la structure de tes donnees), et en possibilites d'evolutions futures (en remplacant SQLite par autre chose). La BD est contenues dans un fichier unique, et il n'y a pas d'admin a faire, brefle, le saut n'est pas si important de XML a une BD. Sinon YAML est pas mal non plus, plus lisible que XML a mon avis.
Le XML me sert uniquement àprésenter les résultats, pour qu'ils soient facilement "exportables" en html, pdf ou je ne sais quoi encore. La sauvegarde dans une bdd ne sera qu'une option, la présentation des résultats de l'exécution est le but du script.
Bref, je me dis, peut-être à tort (?), que c'est XML qui me permettra le plus facilement d'exporter mes résultats au(x) format(s) que je veux.
Mais bon, si tu insistes pour utiliser XML...
Ce que je fais dans les cas comme ca c'est avoir 2 (ou plus) passes: d'abord cree du XML, sans te preoccuper de l'ordre ni du gras. Essaye XML::Simple, XML::Dumper, Data::DumpXML (de tete, je me plante peut etre sur les noms des modules) ou des betes prints. Ensuite je reprends ca avec des outils XML, pour trier et rajouter le gras. C'est pas la seule methode, mais par experience ca correspond a 2 types de traitements assez differents pour meriter d'etre separes: passer de non-xml a du xml, et retravailler du xml avec des outils xml.
Effectivement, ça pourrait bien être plus simple que de tenter de faire les 2 en 1 ... mais ça ne résoud pas mon problème de "polymorphisme" (au sens premier du terme, cad que mes données peuvent être dans des structures différentes).
Mais vraiment, si tu manipules des donnees dont l'habitat naturel est une BD, ca me semble cruel de les transplanter dans du XML sans bonne raison. XML c'est un camion, ca sert a transporter des trucs, pas de residence principale. ;--)
:-)
Paul.
Michel Rodriguez
Paul Bert wrote:
Pour faire court, j'ai un hash qui contient des données, que je voudrais sauvegarder dans un fichier en xml (voire dans une bdd, mais ce sera pour plus tard, une chose à la fois ;-)
La je comprends plus. Pourquoi ne pas sauter l'etape XML et directement utiliser un BD? Ca t'eviterais de faire 2 fois la meme chose. Prends DBI et DBD::SQLite par exemple, et tu perds d'un cote en lisibilite des donnees, mais tu gagne en vitesse, probablement en facilite de traitement (ca depend de la structure de tes donnees), et en possibilites d'evolutions futures (en remplacant SQLite par autre chose). La BD est contenues dans un fichier unique, et il n'y a pas d'admin a faire, brefle, le saut n'est pas si important de XML a une BD. Sinon YAML est pas mal non plus, plus lisible que XML a mon avis.
Mais bon, si tu insistes pour utiliser XML...
Ce que je fais dans les cas comme ca c'est avoir 2 (ou plus) passes: d'abord cree du XML, sans te preoccuper de l'ordre ni du gras. Essaye XML::Simple, XML::Dumper, Data::DumpXML (de tete, je me plante peut etre sur les noms des modules) ou des betes prints. Ensuite je reprends ca avec des outils XML, pour trier et rajouter le gras. C'est pas la seule methode, mais par experience ca correspond a 2 types de traitements assez differents pour meriter d'etre separes: passer de non-xml a du xml, et retravailler du xml avec des outils xml.
Mais vraiment, si tu manipules des donnees dont l'habitat naturel est une BD, ca me semble cruel de les transplanter dans du XML sans bonne raison. XML c'est un camion, ca sert a transporter des trucs, pas de residence principale. ;--)
-- Michel Rodriguez Perl & XML http://www.xmltwig.com
Paul Bert wrote:
Pour faire court, j'ai un hash qui contient des données, que je voudrais
sauvegarder dans un fichier en xml (voire dans une bdd, mais ce sera
pour plus tard, une chose à la fois ;-)
La je comprends plus. Pourquoi ne pas sauter l'etape XML et directement
utiliser un BD? Ca t'eviterais de faire 2 fois la meme chose. Prends DBI
et DBD::SQLite par exemple, et tu perds d'un cote en lisibilite des
donnees, mais tu gagne en vitesse, probablement en facilite de
traitement (ca depend de la structure de tes donnees), et en
possibilites d'evolutions futures (en remplacant SQLite par autre
chose). La BD est contenues dans un fichier unique, et il n'y a pas
d'admin a faire, brefle, le saut n'est pas si important de XML a une BD.
Sinon YAML est pas mal non plus, plus lisible que XML a mon avis.
Mais bon, si tu insistes pour utiliser XML...
Ce que je fais dans les cas comme ca c'est avoir 2 (ou plus) passes:
d'abord cree du XML, sans te preoccuper de l'ordre ni du gras. Essaye
XML::Simple, XML::Dumper, Data::DumpXML (de tete, je me plante peut etre
sur les noms des modules) ou des betes prints. Ensuite je reprends ca
avec des outils XML, pour trier et rajouter le gras. C'est pas la seule
methode, mais par experience ca correspond a 2 types de traitements
assez differents pour meriter d'etre separes: passer de non-xml a du
xml, et retravailler du xml avec des outils xml.
Mais vraiment, si tu manipules des donnees dont l'habitat naturel est
une BD, ca me semble cruel de les transplanter dans du XML sans bonne
raison. XML c'est un camion, ca sert a transporter des trucs, pas de
residence principale. ;--)
--
Michel Rodriguez
Perl & XML
http://www.xmltwig.com
Pour faire court, j'ai un hash qui contient des données, que je voudrais sauvegarder dans un fichier en xml (voire dans une bdd, mais ce sera pour plus tard, une chose à la fois ;-)
La je comprends plus. Pourquoi ne pas sauter l'etape XML et directement utiliser un BD? Ca t'eviterais de faire 2 fois la meme chose. Prends DBI et DBD::SQLite par exemple, et tu perds d'un cote en lisibilite des donnees, mais tu gagne en vitesse, probablement en facilite de traitement (ca depend de la structure de tes donnees), et en possibilites d'evolutions futures (en remplacant SQLite par autre chose). La BD est contenues dans un fichier unique, et il n'y a pas d'admin a faire, brefle, le saut n'est pas si important de XML a une BD. Sinon YAML est pas mal non plus, plus lisible que XML a mon avis.
Mais bon, si tu insistes pour utiliser XML...
Ce que je fais dans les cas comme ca c'est avoir 2 (ou plus) passes: d'abord cree du XML, sans te preoccuper de l'ordre ni du gras. Essaye XML::Simple, XML::Dumper, Data::DumpXML (de tete, je me plante peut etre sur les noms des modules) ou des betes prints. Ensuite je reprends ca avec des outils XML, pour trier et rajouter le gras. C'est pas la seule methode, mais par experience ca correspond a 2 types de traitements assez differents pour meriter d'etre separes: passer de non-xml a du xml, et retravailler du xml avec des outils xml.
Mais vraiment, si tu manipules des donnees dont l'habitat naturel est une BD, ca me semble cruel de les transplanter dans du XML sans bonne raison. XML c'est un camion, ca sert a transporter des trucs, pas de residence principale. ;--)
-- Michel Rodriguez Perl & XML http://www.xmltwig.com
Jean-Michel Hiver
1. mes données peuvent changer dans mon hash (ie les clés, et par conséquent les valeurs aussi, changent d'une exécution à l'autre). Or, je souhaite ordonner les clés d'une certaine manière (que je connais en fonction de certains paramètres contenus dans le hash lui-même).
Les hachages sont par natures non-ordonnes. Si tu as besoin de les ordonner d'une certaine maniere, tu est en train d'utiliser une mauvaise structure de donnees.
2. au moment où je sauve mes données dans le fichier xml, je voudrais "en mettre certaine en gras" (ok, ça n'a pas de sens en xml, mais je les collerai juste dans une balise qui sera interprétée pour faire cela). Comme ces données correpondent à des expressions régulières, je dois le faire en perl.
Ta structure de donnees doit quelque part refleter le fait que cet element est en gras. Rien a voir avec XML.
Et à cause de ces 2 points, je ne sais pas trop comment faire pour créer mon fichier.
J'ai bien une idée en tête, mais je ne sais pas si elle tient la route, s'il n'y a pas plus simple, ...
En gros, je pensais "attacher" une méthode à chaque "clé" pour dumper la valeur correspondante en xml, de la manière que je veux. Avant d'écrire réellement dans le fichier, je passe mon texte dans un parser qui me recherche les données "à mettre en gras".
Une meilleure idée ? Une manière simple de faire cela ?
Eh bien si tu veux transformer une structure en XML tu peux utiliser mon super systeme de template XML Petal, qui te permettra d'ecrire un template XML pour ta structure.
Ou alors tu peux utiliser XML::Simple, qui est effectivement vraiment tres simple :)
Pour ce qui est de parser le ficher, par exemple pour le transformer en une autre structure, tu peux toujours utiliser mes outils si ca te tente ...
1. mes données peuvent changer dans mon hash (ie les clés, et par
conséquent les valeurs aussi, changent d'une exécution à l'autre).
Or, je souhaite ordonner les clés d'une certaine manière (que je
connais en fonction de certains paramètres contenus dans le hash
lui-même).
Les hachages sont par natures non-ordonnes. Si tu as besoin de les
ordonner d'une certaine maniere, tu est en train d'utiliser une mauvaise
structure de donnees.
2. au moment où je sauve mes données dans le fichier xml, je voudrais
"en mettre certaine en gras" (ok, ça n'a pas de sens en xml, mais je les
collerai juste dans une balise qui sera interprétée pour faire cela).
Comme ces données correpondent à des expressions régulières, je dois le
faire en perl.
Ta structure de donnees doit quelque part refleter le fait que cet
element est en gras. Rien a voir avec XML.
Et à cause de ces 2 points, je ne sais pas trop comment faire pour créer
mon fichier.
J'ai bien une idée en tête, mais je ne sais pas si elle tient la route,
s'il n'y a pas plus simple, ...
En gros, je pensais "attacher" une méthode à chaque "clé" pour dumper la
valeur correspondante en xml, de la manière que je veux. Avant d'écrire
réellement dans le fichier, je passe mon texte dans un parser qui me
recherche les données "à mettre en gras".
Une meilleure idée ? Une manière simple de faire cela ?
Eh bien si tu veux transformer une structure en XML tu peux utiliser mon
super systeme de template XML Petal, qui te permettra d'ecrire un
template XML pour ta structure.
Ou alors tu peux utiliser XML::Simple, qui est effectivement vraiment
tres simple :)
Pour ce qui est de parser le ficher, par exemple pour le transformer en
une autre structure, tu peux toujours utiliser mes outils si ca te tente ...
1. mes données peuvent changer dans mon hash (ie les clés, et par conséquent les valeurs aussi, changent d'une exécution à l'autre). Or, je souhaite ordonner les clés d'une certaine manière (que je connais en fonction de certains paramètres contenus dans le hash lui-même).
Les hachages sont par natures non-ordonnes. Si tu as besoin de les ordonner d'une certaine maniere, tu est en train d'utiliser une mauvaise structure de donnees.
2. au moment où je sauve mes données dans le fichier xml, je voudrais "en mettre certaine en gras" (ok, ça n'a pas de sens en xml, mais je les collerai juste dans une balise qui sera interprétée pour faire cela). Comme ces données correpondent à des expressions régulières, je dois le faire en perl.
Ta structure de donnees doit quelque part refleter le fait que cet element est en gras. Rien a voir avec XML.
Et à cause de ces 2 points, je ne sais pas trop comment faire pour créer mon fichier.
J'ai bien une idée en tête, mais je ne sais pas si elle tient la route, s'il n'y a pas plus simple, ...
En gros, je pensais "attacher" une méthode à chaque "clé" pour dumper la valeur correspondante en xml, de la manière que je veux. Avant d'écrire réellement dans le fichier, je passe mon texte dans un parser qui me recherche les données "à mettre en gras".
Une meilleure idée ? Une manière simple de faire cela ?
Eh bien si tu veux transformer une structure en XML tu peux utiliser mon super systeme de template XML Petal, qui te permettra d'ecrire un template XML pour ta structure.
Ou alors tu peux utiliser XML::Simple, qui est effectivement vraiment tres simple :)
Pour ce qui est de parser le ficher, par exemple pour le transformer en une autre structure, tu peux toujours utiliser mes outils si ca te tente ...
Ah oui, j'ai failli oublier! Puisqu'on en est a faire de la pub pour ses outils ;--)
Si tu veux te promener dans ta structure sans vraiment savoir comment elle est fichu, tu peux peut-etre utiliser Data::Traverse, qui est la: http://xmltwig.com/module/data-traverse/ Ca te permet de creer un iterateur qui sait ou il est dans la structure.
-- Michel Rodriguez Perl & XML http://www.xmltwig.com
Ah oui, j'ai failli oublier! Puisqu'on en est a faire de la pub pour ses
outils ;--)
Si tu veux te promener dans ta structure sans vraiment savoir comment
elle est fichu, tu peux peut-etre utiliser Data::Traverse, qui est la:
http://xmltwig.com/module/data-traverse/ Ca te permet de creer un
iterateur qui sait ou il est dans la structure.
--
Michel Rodriguez
Perl & XML
http://www.xmltwig.com
Ah oui, j'ai failli oublier! Puisqu'on en est a faire de la pub pour ses outils ;--)
Si tu veux te promener dans ta structure sans vraiment savoir comment elle est fichu, tu peux peut-etre utiliser Data::Traverse, qui est la: http://xmltwig.com/module/data-traverse/ Ca te permet de creer un iterateur qui sait ou il est dans la structure.
-- Michel Rodriguez Perl & XML http://www.xmltwig.com
Jean-Michel Hiver
Michel Rodriguez wrote:
Ah oui, j'ai failli oublier! Puisqu'on en est a faire de la pub pour ses outils ;--)
Si tu veux te promener dans ta structure sans vraiment savoir comment elle est fichu, tu peux peut-etre utiliser Data::Traverse, qui est la: http://xmltwig.com/module/data-traverse/ Ca te permet de creer un iterateur qui sait ou il est dans la structure.
XML::Twig est, au passage, un module fort agreable :)
Michel Rodriguez wrote:
Ah oui, j'ai failli oublier! Puisqu'on en est a faire de la pub pour ses
outils ;--)
Si tu veux te promener dans ta structure sans vraiment savoir comment
elle est fichu, tu peux peut-etre utiliser Data::Traverse, qui est la:
http://xmltwig.com/module/data-traverse/ Ca te permet de creer un
iterateur qui sait ou il est dans la structure.
XML::Twig est, au passage, un module fort agreable :)
Ah oui, j'ai failli oublier! Puisqu'on en est a faire de la pub pour ses outils ;--)
Si tu veux te promener dans ta structure sans vraiment savoir comment elle est fichu, tu peux peut-etre utiliser Data::Traverse, qui est la: http://xmltwig.com/module/data-traverse/ Ca te permet de creer un iterateur qui sait ou il est dans la structure.
XML::Twig est, au passage, un module fort agreable :)
Michel Rodriguez
Jean-Michel Hiver wrote:
XML::Twig est, au passage, un module fort agreable :)
Je vois que tu n'a pas a le maintenir ;--(
Mais merci quand meme.
-- Michel Rodriguez Perl & XML http://www.xmltwig.com
Jean-Michel Hiver wrote:
XML::Twig est, au passage, un module fort agreable :)
Je vois que tu n'a pas a le maintenir ;--(
Mais merci quand meme.
--
Michel Rodriguez
Perl & XML
http://www.xmltwig.com
