Discussion :

[BSmum]

Bonjour:
Je veux transformer des fichiers de configuration cisco en des fichiers xml.
Le fichier de configuration a la forme suivante:
***************
Current configuration : 4764 bytes
!
! NVRAM config last updated at 08:18:34 UTC Fri Sep 17 2010
!
version 12.2
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname KSB-SW21
!
boot-start-marker
boot-end-marker
!
enable secret
no aaa new-model
system mtu routing 1500
ip subnet-zero
!
ip dhcp snooping vlan 1,10,20,30,40
ip dhcp snooping
!
cluster commander-address - member 5 name - vlan 1
!
!
!
!
!
spanning-tree mode pvst
spanning-tree extend system-id
!
vlan internal allocation policy ascending
!
!
!
interface FastEthernet0/1
switchport access vlan 10
switchport mode access
switchport nonegotiate
switchport voice vlan 20
spanning-tree portfast
!
interface FastEthernet0/2
switchport access vlan 10
switchport mode access
switchport nonegotiate
switchport voice vlan 20
spanning-tree portfast

......
***************

je me depuis longtemps mais pas de résultat!!
avez vous des propositions??
Merci d'avance.

[polymorphisme]

Bonjour,

c'est clairement faisable, mais je ne connais pas d'autres méthodes que de créer une classe à la main pour obtenir ce xml.

En gros, il faut définit les éléments de ton fichier XML, la correspondance entre le texte de ton fichier texte et les éléments XML, puis écrire la classe reflétant cette correspondance.

[alain.couthures]

Bonjour,

Une autre approche, moins académique peut-être, consiste à utiliser XSLT pour faire celà.

Avec XSLT 1.0, il est nécessaire de d'abord rajouter un élément racine. Avec XSLT 2.0, grâce à la fonction unparsed-text(), ce n'est même pas la peine !

-Alain

[thelvin]

Une autre approche, moins académique peut-être, consiste à utiliser XSLT pour faire celà.

Avec XSLT 1.0, il est nécessaire de d'abord rajouter un élément racine. Avec XSLT 2.0, grâce à la fonction unparsed-text(), ce n'est même pas la peine !

Moins académique et surtout moins pragmatique -_-°. XSLT peut être bon pour transformer des données qui sont déjà au format XML, mais pas pour l'inverse.

[alain.couthures]

Moins académique et surtout moins pragmatique -_-°. XSLT peut être bon pour transformer des données qui sont déjà au format XML, mais pas pour l'inverse.

XPath 2.0 intègre beaucoup de fonctions de manipulation de chaines supplémentaires.

XSLT n'a pas son pareil pour bien générer du XML, à part peut-être XQuery.

Mais c'est vrai qu'il faut nativement penser en récursif !

-Alain

[polymorphisme]

Bonjour,

je n'ai jamais vraiment chercher pourquoi XSLT n'était pas très performant pour manipuler du texte. Auriez-vous des tests le démontrant ?

[tsuji]

Si l'intégration m'oblige, je n'hesite pas de prendre d'avantage de unparsed-text(): on peut aussi dire que la fonction est faite pour ça.

Perl est fort à traiter des fichiers textuels, ça n'empeche pas des travailleurs de logiciels de les traiter avec un langage d'une porter plus limitée comme Basic - pour faire plus de contrast.

Xml n'est souvent pas réputé d'être concis, mais ça n'empeche pas de devenir un format porteur de méssages à longue distance qui consume "bandwidth". Est-ce que xml est fait pour ça particulièrement?

Je ne vois pas de raison d'extrapoler trop d'après des goûts personnels et d'en prendre comme absolus jusqu'à agresser les autres collègues à cet égard.

[thelvin]

Si l'intégration m'oblige, je n'hesite pas de prendre d'avantage de unparsed-text(): on peut aussi dire que la fonction est faite pour ça.

Absolument. Mais le si, en début de phrase, est le mot-clé de la phrase. Sans aller jusqu'à parler d'obliger, lorsque la situation dans laquelle on se trouve favorise déjà XSLT 2.0, on peut se rappeler qu'on a pas besoin d'avoir peur du texte grâce à unparsed-text().

Et dans ce cas-là seulement.

Perl est fort à traiter des fichiers textuels, ça n'empeche pas des travailleurs de logiciels de les traiter avec un langage d'une porter plus limitée comme Basic - pour faire plus de contrast.

J'en sais rien, Perl c'est pas mon truc.

Xml n'est souvent pas réputé d'être concis, mais ça n'empeche pas de devenir un format porteur de méssages à longue distance qui consume "bandwidth". Est-ce que xml est fait pour ça particulièrement?

Littéralement oui. XML est étudié pour mettre tout le monde d'accord universellement sur comment représenter des données, et quelles données sont représentées exactement par tel ou tel document XML.
À l'époque cela concernait absolument tout échange d'une application à l'autre, que ce soit à travers le réseau, entre applications à travers les pipes, à travers des fichiers, ou d'une version à l'autre.

De nos jours ça semble moins intéressant grâce à JSON ou Google Protocol Buffer, mais les habitudes sont tenaces, et il reste des cas pathologiques sans XML.

Par ailleurs, pas mal de gens se jettent sur XML sans se soucier de justifier ce choix. Pourquoi pas si ça leur fait gagner du temps et qu'ils comprennent à l'à peu près comment ça marche. Mais là nous parlions de perdre du temps, et d'une technologie qui a juste rien à voir, donc fondamentalement incompréhensible vis-à-vis de l'objectif visé.

Je ne vois pas de raison d'extrapoler trop d'après des goûts personnels et d'en prendre comme absolus jusqu'à agresser les autres collègues à cet égard.

Bah en voilà deux : le coût en temps de mise en place et d'apprentissage ; et le coût de la maintenance, qui découle de la logique de mise en œuvre.
En plus je suis désolé, mais dire à quelqu'un que ce qu'il a dit à quelqu'un d'autre ne marche pas, ça passera toujours comme agressif. Non, c'est la vérité ni plus ni moins, pourquoi je devrais obliger les générations futures qui viendront lire des trucs, à écouter des mauvais conseils et essayer d'en tirer quelque chose ? Si c'est pas bon c'est pas bon, et je le dis, c'est pas dans ce sens qu'il faut aller, et tant pis pour l'amour-propre du monsieur.

De toute façon des professionnels ne discuteraient pas de cela si longtemps : "quand la seule chose qu'on a c'est un marteau, tous les problèmes ressemblent à un clou," c'est connu, parfaitement vérifié, et on en voit très bien les défauts.

[polymorphisme]

Bonjour tsuji,

Xml n'est souvent pas réputé d'être concis, mais ça n'empeche pas de devenir un format porteur de méssages à longue distance qui consume "bandwidth". Est-ce que xml est fait pour ça particulièrement?

Je crois que les Web Services l'utilisent tel quel.
Après, je sais qu'il existe des applications dont le but est réduire la taille du XML. Par exemple, en supprimant les espaces blancs inutiles, en modifiant le type des éléments, en compressant les données, ...

[tsuji]

Bonjour M Roche,
C'est entendu, merci; j'ai bien conscience de cela et bien d'autres venant avec. C'est absolument impossible autant qu'inutile d'y plunger dedans, ça ramène trop loin du sujet malheursement.
-tsuji