Initiation en xml
Fermé
nita2006
Messages postés
79
Date d'inscription
samedi 19 janvier 2008
Statut
Membre
Dernière intervention
31 juillet 2008
-
4 juin 2008 à 11:00
sebsauvage Messages postés 32893 Date d'inscription mercredi 29 août 2001 Statut Modérateur Dernière intervention 21 octobre 2019 - 4 juin 2008 à 13:08
sebsauvage Messages postés 32893 Date d'inscription mercredi 29 août 2001 Statut Modérateur Dernière intervention 21 octobre 2019 - 4 juin 2008 à 13:08
A voir également:
- Initiation en xml
- Xml viewer - Télécharger - Édition & Programmation
- Office xml handler - Télécharger - Traitement de texte
- Driveimage xml - Télécharger - Sauvegarde
- Oxygen xml - Télécharger - Divers Web & Internet
- Convertir word en xml - Forum Word
7 réponses
Utilisateur anonyme
4 juin 2008 à 11:15
4 juin 2008 à 11:15
Salut, XML n'est pas un langage de programmation mais une façon de représenter les données. En fait c'est à toi de décider comment faire ton fichier XML, sa structure peut faire penser à un arbre, exemple :
Tout dépend jusqu'où tu veux aller. Le XML peut être utilisé pour stocker n'importe quoi, et il permet bien sûr d'être échangé facilement d'une application à l'autre.
Exemple de XML utilisé en pratique : un extrait de fichier XMLTV (pour les guides TV électroniques) :
Là tu vois comment est organisé le fichier XML. Après bien sûr, à l'application de traiter ce format (dans ce cas par exemple, une TV qui affiche à l'écran le programme TV).
Sur le site www.developpez.net j'ai vu quelques exemples.
<contacts> <personne> <nom>A</nom> <prenom>A</prenom> </personne> <personne> <nom>B</nom> <prenom>B</prenom> </personne> ... </contacts>
Tout dépend jusqu'où tu veux aller. Le XML peut être utilisé pour stocker n'importe quoi, et il permet bien sûr d'être échangé facilement d'une application à l'autre.
Exemple de XML utilisé en pratique : un extrait de fichier XMLTV (pour les guides TV électroniques) :
<channel id="tf1.fr"> <display-name lang="fr">TF1</display-name> <display-name>TF1</display-name> <icon src="http://www.lyngsat-logo.com/logo/tv/tt/tf1.jpg" /> </channel> .... <programme start="20080602101500 +0200" stop="20080602110500 +0200" channel="tf1.fr"> <title>7 à la maison</title> <desc lang="fr">Série familiale américaine (7th Heaven). Saison 4, 1999-2000 (8/22).</desc> <category>série</category> <url>https://www.moustique.be/index.php <episode-num system="onscreen">(8/22)</episode-num> <subtitles type="teletext" /> </programme>
Là tu vois comment est organisé le fichier XML. Après bien sûr, à l'application de traiter ce format (dans ce cas par exemple, une TV qui affiche à l'écran le programme TV).
Sur le site www.developpez.net j'ai vu quelques exemples.
LegGohan
Messages postés
200
Date d'inscription
vendredi 21 septembre 2007
Statut
Membre
Dernière intervention
2 août 2017
54
4 juin 2008 à 11:04
4 juin 2008 à 11:04
Contact moi en mp si tu es interessé par des cours de xml que j'ai eu cette année en licence pro.
Je pense qu'ils sont pas mal du tout!!!
Je pense qu'ils sont pas mal du tout!!!
sebsauvage
Messages postés
32893
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019
15 659
4 juin 2008 à 11:06
4 juin 2008 à 11:06
en fait le langage avce lequel je dois programmer c'est du xml
Oups... XML n'est pas un langage de programmation.
Voir: http://sebsauvage.net/comprendre/xml/index.html
XML n'est pas une fin en soit. C'est une des nombreuses méthodes pour structurer des données.
Ne jamais sous-estimer la puissance des bases de données (même SQLite !).
XML est généralement utilisé à tort et à travers.
Oups... XML n'est pas un langage de programmation.
Voir: http://sebsauvage.net/comprendre/xml/index.html
XML n'est pas une fin en soit. C'est une des nombreuses méthodes pour structurer des données.
Ne jamais sous-estimer la puissance des bases de données (même SQLite !).
XML est généralement utilisé à tort et à travers.
sebsauvage
Messages postés
32893
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019
15 659
4 juin 2008 à 11:22
4 juin 2008 à 11:22
Pour illustrer mon propos:
Pourquoi je préfère SQLite à XML ?
SQLite est plus compact (XML gaspille une place énorme): Pour les mêmes données, l'XML prendra au minimum le double de place ! (à cause des balises).
XML n'est pas efficace en matière de stockage. Il est incroyablement verbeux.
XML est lent. Très lent. Lire de gros fichiers XML est horriblement lent, et ça bouffe beaucoup de CPU.
SQLite est extrêmenent rapide. Même sans les indexes, SQLite est plus rapide que toutes les API XML que j'ai pu tester.
Faites des tests de recherche dans un grand ensemble de données, vous verrez la différence (Essayez 1 Go pour voir).
XML est lourd à programmer.
Que vous choisissiez DOM ou SAX, lire un fichier XML est horriblement lourd à programmer.
A comparer à une simple requête SQL, y'a pas photo.
Ou même un simple fichier tabulaire.
En prime, le SQL peut me faire des filtres, des tris, des croisements de données, des calculs... tout un tas de trucs que vous allez reprogrammer si vous travaillez en XML.
Pourquoi ré-inventer la roue ? Vous aimez perdre du temps ?
Sans compter que les serveurs de bases de données sont optimisés pour ce genre de travail, et qu'ils feront un bien meilleur boulot que ce que vous pourrez programmer.
SQLite est portable également: Windows, Mac, Linux... des grands systèmes jusqu'aux PDA
(SQLite est utilisé dans l'iPhone d'Apple)
Je peux transférer ma base SQLite d'un système à l'autre et l'utiliser directement.
Une base SQLite est autant auto-descriptive d'un fichier XML.
Donc XML n'a aucun avantage là dessus.
Essayez de modifier une partie d'un fichier XML. Vous allez vous tirer une balle.
Soit vous passez par DOM, et ça bouffe une quantité pas possible de mémoire, soit vous passez par SAX et vous êtes bon pour ré-écrire tout le fichier. Non merci.
En SQL, j'ai un ordre UPDATE à lancer.
Essayez de stocker des données binaire en XML. Bon courage (base64 ?)
Les bases de données gèrent les données binaires sans problème, et de manière efficace.
La plupart des bases de données permettent un typage des données, inexistant en XML.
Les bases de données permettent la mise en place de contraintes pour assurer une plus grande cohérence des données.
Inexistant en XML.
Enfin, quand vous écrivez un fichier XML, vous n'avez aucune garantie d'intégrité des données.
SQLite respecte le propriétés ACID: Je suis sûr que mes données ne seront jamais en vrac.
Je parle de SQLite, mais la plupart de ces propriétés s'appliquent également aux autres bases de données (Oracle, mySQL, etc.)
XML est une solution à la recherche d'un problème, j'en suis de plus en plus convaincu (et j'ai quelques années de travail en milieu professionel derrière moi).
Pourquoi je préfère SQLite à XML ?
SQLite est plus compact (XML gaspille une place énorme): Pour les mêmes données, l'XML prendra au minimum le double de place ! (à cause des balises).
XML n'est pas efficace en matière de stockage. Il est incroyablement verbeux.
XML est lent. Très lent. Lire de gros fichiers XML est horriblement lent, et ça bouffe beaucoup de CPU.
SQLite est extrêmenent rapide. Même sans les indexes, SQLite est plus rapide que toutes les API XML que j'ai pu tester.
Faites des tests de recherche dans un grand ensemble de données, vous verrez la différence (Essayez 1 Go pour voir).
XML est lourd à programmer.
Que vous choisissiez DOM ou SAX, lire un fichier XML est horriblement lourd à programmer.
A comparer à une simple requête SQL, y'a pas photo.
Ou même un simple fichier tabulaire.
En prime, le SQL peut me faire des filtres, des tris, des croisements de données, des calculs... tout un tas de trucs que vous allez reprogrammer si vous travaillez en XML.
Pourquoi ré-inventer la roue ? Vous aimez perdre du temps ?
Sans compter que les serveurs de bases de données sont optimisés pour ce genre de travail, et qu'ils feront un bien meilleur boulot que ce que vous pourrez programmer.
SQLite est portable également: Windows, Mac, Linux... des grands systèmes jusqu'aux PDA
(SQLite est utilisé dans l'iPhone d'Apple)
Je peux transférer ma base SQLite d'un système à l'autre et l'utiliser directement.
Une base SQLite est autant auto-descriptive d'un fichier XML.
Donc XML n'a aucun avantage là dessus.
Essayez de modifier une partie d'un fichier XML. Vous allez vous tirer une balle.
Soit vous passez par DOM, et ça bouffe une quantité pas possible de mémoire, soit vous passez par SAX et vous êtes bon pour ré-écrire tout le fichier. Non merci.
En SQL, j'ai un ordre UPDATE à lancer.
Essayez de stocker des données binaire en XML. Bon courage (base64 ?)
Les bases de données gèrent les données binaires sans problème, et de manière efficace.
La plupart des bases de données permettent un typage des données, inexistant en XML.
Les bases de données permettent la mise en place de contraintes pour assurer une plus grande cohérence des données.
Inexistant en XML.
Enfin, quand vous écrivez un fichier XML, vous n'avez aucune garantie d'intégrité des données.
SQLite respecte le propriétés ACID: Je suis sûr que mes données ne seront jamais en vrac.
Je parle de SQLite, mais la plupart de ces propriétés s'appliquent également aux autres bases de données (Oracle, mySQL, etc.)
XML est une solution à la recherche d'un problème, j'en suis de plus en plus convaincu (et j'ai quelques années de travail en milieu professionel derrière moi).
nita2006
Messages postés
79
Date d'inscription
samedi 19 janvier 2008
Statut
Membre
Dernière intervention
31 juillet 2008
13
4 juin 2008 à 11:36
4 juin 2008 à 11:36
Oui tout ca j ai compris , mais je fais comment pour le voir en concret
la par exemple le bout de code que tu m'as fait
<contacts>
<personne>
<nom>A</nom>
<prenom>A</prenom>
</personne>
<personne>
<nom>B</nom>
<prenom>B</prenom>
</personne>
...
</contacts>
en quoi je peux le concrétiser ? voir ce resultat ?
la par exemple le bout de code que tu m'as fait
<contacts>
<personne>
<nom>A</nom>
<prenom>A</prenom>
</personne>
<personne>
<nom>B</nom>
<prenom>B</prenom>
</personne>
...
</contacts>
en quoi je peux le concrétiser ? voir ce resultat ?
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
sebsauvage
Messages postés
32893
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019
15 659
4 juin 2008 à 11:39
4 juin 2008 à 11:39
en quoi je peux le concrétiser ? voir ce resultat ?
Le résultat, tu l'as sous les yeux: Une structure de données prévue pour stocker un type de données bien précis.
Après, tu peux créer des programmes pour le transformer: en HTLM, en fichier CSV, etc.
Ce sont juste des données stockées: C'est ton programme qui va déterminer le résultat du traitement de ces données.
Le résultat, tu l'as sous les yeux: Une structure de données prévue pour stocker un type de données bien précis.
Après, tu peux créer des programmes pour le transformer: en HTLM, en fichier CSV, etc.
Ce sont juste des données stockées: C'est ton programme qui va déterminer le résultat du traitement de ces données.
nita2006
Messages postés
79
Date d'inscription
samedi 19 janvier 2008
Statut
Membre
Dernière intervention
31 juillet 2008
13
4 juin 2008 à 11:58
4 juin 2008 à 11:58
ok , et si alors j ai 200 000 entrées je vais de voir entrer 200 000 personnes , tu penses que c'est evident .?
et je fais comment pour le prog qui permet de l'afficher en html
et je fais comment pour le prog qui permet de l'afficher en html
sebsauvage
Messages postés
32893
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019
15 659
4 juin 2008 à 13:08
4 juin 2008 à 13:08
Pour 200000 entrées, ça me semble aberrant d'utiliser XML.
Une base de données sera bien mieux adaptée (beaucoup plus rapide, plus facile à progammer...)
Une base de données sera bien mieux adaptée (beaucoup plus rapide, plus facile à progammer...)