Discussion :

[epeios]

Voilà quelques années que j'utilise intensivement le format XML pour divers usages. J'ai rapidement développé un outil qui devait me faciliter l'écriture de fichiers dans ce format. Ayant besoin de l'améliorer, j'ai recherché s'il n'existait pas une alternative qui le remplacerait avantageusement. A ma grande surprise, aujourd'hui, comme à l'époque à laquelle j'ai commencé à développer cet outil, une telle alternative n'existe pas.

L'outil en question est une sorte de préprocesseur qui permet, grâce à des directives appartenant à un 'namespace' dédié, d'inclure dans un fichier XML plusieurs autres fichiers XML, de définir et d'utiliser des macros, de définir des variables et d'en tester la valeur, etc., tout cela en incluant ces directives directement dans le fichier XML source (pour plus de détails, voir http://zeusw.org/intl/expp).

Cet outil s'est révèlé extrêmement utile et il me serait très difficile de m'en passer, en particulier pour l'écriture de fichiers de configurations. En tant que développeur, notamment, il m'est souvent nécessaire de mettre en œuvre de nombreuses variantes d'une même configuration de base. Plutôt que d'avoir un fichier XML par variante, grâce à cet outil, j'ai un fichier XML qui regroupe tous les paramètres communs à toutes les variantes, fichier qui est ensuite inclus par des fichiers XML qui contiennent juste les paramètres propres à chaque variante.

Les autres personnes qui utilisent le format XML, comment procèdent-elles pour pouvoir se passer d'un tel préprocesseur ? Je sais que l'on peut parvenir au même résultat avec XSLT (bien que pas vraiment conçu pour un tel usage), ce qui nécessite cependant de recourir à un fichier à part contenant les directives XSL, alors qu'une solution permettant d'inclure les directives directement dans le fichier XML source me semble bien plus pratique ...

[Morbo]

Hello,
C'est en effet un besoin qui émerge assez vite quand on se met à utiliser XML. Pour ma part, j'ai commencé par utiliser cocoon (un portail web) qui permet de définir des chaines de transformations modulaires en fonction de requêtes HTTP.

Plus généralement, la norme XProc répond à ce besoin :
http://www.developpez.net/forums/d92...mandation-w3c/
Avec Calumet, il y a même une interface graphique assez sympa pour modéliser.

J'essaie de m'y mettre, non sans mal, avec eXist notamment et la contrainte de vouloir gérer du XSLT-2.0.

[thelvin]

En ce qui me concerne, j'ai pas tellement le problème. De temps en temps j'ai besoin d'un mécanisme similaire aux macros, et d'éclater mon information en plusieurs fichiers. Mais les formats et outils consommateurs du XML adressent ce besoin de façon simple.

Quant aux formats que je définis moi-même, rien n'a jamais justifié de faire un système similaire aux macros, et je prévois presque toujours de les rendre éclatables en plusieurs fichiers pour séparer les responsabilités et garder les tailles raisonnables.

'Faudrait que je tombe sur le problème un jour, pour mieux le comprendre.

[alain.couthures]

Bien avant que les premières implémentations de XProc n'apparaissent, j'ai développé un moteur comparable (http://sourceforge.net/projects/txs) d'abord pour .Net puis pour PHP.

Basé sur XSLT 1.0 et sur l'API DOM, il me permet de définir des langages XML spécifiques comme celui de expp. Par exemple, j'ai, grâce à lui, construit tout un environnement d'assemblage de fichiers source XSLT, Javascript et CSS pour mon implémentation XForms.

Décidément, j'apprécie de plus en plus cette non distinction programme/donnée si naturelle en XML...

-Alain

[epeios]

XProc est en effet intéressant, mais ne correspond pas à mes besoins, rien que par le fait que les instructions définies pas cette normes doivent être placées dans un fichier dédié.

Quant aux autres mécanismes évoqués dans ce fil de discussion, à supposer qu'ils répondent à mes attentes, leur mise en œuvre me semble trop contraignante pour l'usage que j'en aurais.

A titre d'exemple, prenons le fichier de configuration d'un moteur de base de données auquel on doit naturellement préciser où se situe physiquement la base. Dans mon cas de figure, toutes les bases de données se situent dans le même répertoire. Comme je dois fréquemment changer de base de données, le fichier de configuration ressemblerait, sans préprocesseur, à ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
<Configuration>
    ...
    <!--DBDirectory>/home/user/DBs/Test</DBDirectory-->
    <DBDirectory>/home/user/DBs/Food</DBDirectory>
    <!--DBDirectory>/home/user/DBs/Wine</DBDirectory-->
    <!--DBDirectory>/home/user/DBs/Cactus</DBDirectory-->
    <!--DBDirectory>/home/user/DBs/Flower</DBDirectory-->
    ...
</Configuration>

Pour sélectionner une base de données, il faut ainsi décommenter la ligne correspondante et commenter toutes les autres.

Avec le préprocesseur, le fichier de configuration ressemble à cela :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
<Configuration xmlns:xpp="http://zeusw.org/epeios/xpp">
    <xpp:define name="DBName">
        <xpp:bloc>Food</xpp:bloc>
    </xpp:define>
    <xpp:set name="OS" value="Linux"/>
    <!--xpp:set name="OS" value="Windows"/-->
    <xpp:define name="LinuxDBRootDir">
        <xpp:bloc>/home/user/DBs</xpp:bloc>
    </xpp:define>
    <xpp:define name="WindowsDBRootDir">
        <xpp:bloc>D:/DBs</xpp:bloc>
    </xpp:define>
    <xpp:ifeq select="OS" value="Windows">
        <xpp:define name="DBRootDir">
            <xpp:expand select="WindowsDBRootDir"/>
        </xpp:define>
    </xpp:ifeq>
    <xpp:ifeq select="OS" value="Linux">
        <xpp:define name="DBRootDir">
            <xpp:expand select="LinuxDBRootDir"/>
        </xpp:define>
    </xpp:ifeq>
    ...
    <DBDirectory>
        <xpp:expand select="DBRootDir"/>
        <xpp:bloc>/</xpp:bloc>
        <xpp:expand select="DBName"/>
    </DBDirectory>
    ...
</Configuration>

Pour changer de base de donnée, il me suffit de mettre son nom comme définition de la macro "DBName". En outre, ce moteur de base de données tournant indifféremment sous Windows et sous Linux, ce fichier de configuration s'adapte facilement à l'une ou l'autre plateforme grâce à la variable "OS".

Bref, rien de bien sophistiqué, mais ô combien pratique, et cela m'étonne qu'il n'y ai pas ne fût-ce qu'une ébauche de norme définissant des mécanismes similaires ...

[Morbo]

Ben, tu pourrais formaliser la même chose assez facilement en XQuery mais ça a l'inconvénient de ne plus être du XML.

Et avec XProc tu peux avoir tes documents sources "inline" et donc dans un même document XML définir donnée et transformation à appliquer.

Avec XSL-T (et sans doute plus facilement en XSL-T 2.0), on devrait pouvoir même définir dans une feuille de style générique les traitements que font ton programme actuel pour traiter ta grammaire "xpp".

Je ne saisis pas bien ce que tu entends par "instructions définies pas cette normes doivent être placées dans un fichier dédié".

[thelvin]

Oui, bof. Chacun son truc, je suppose. Solutions similaires tout aussi pratiques sans création de processus de ce genre :

- Avoir un fichier final pour chaque configuration possible, et copier celui qu'on veut vers le nom du fichier qui sera effectivement lu par l'application.
- En général les configs et données XML sont éclatables en plusieurs fichiers, soit qui se référencent les uns les autres, soit qu'on choisit de référencer dans la ligne de commande ou autre option. Éclater les différentes confs en différents fichiers et référencer ceux qu'on veut et pas les autres.

L'exemple est un peu trop trivial pour me convaincre... Sans compter que le faire à coup de XSLT évite d'inventer son propre format et n'est pas plus contraignant. Écrire une nouvelle XSLT*à chaque fois ne me semble pas beaucoup plus compliqué qu'écrire de nouveaux xpp à chaque fois.

[wiztricks]

Salut,

Je ne fais que passer et je n'ai qu'un bout de doigt de pied dans XML.
Lorsque, je vois cela:

<Configuration>
...
<!--DBDirectory>/home/user/DBs/Test</DBDirectory-->
<DBDirectory>/home/user/DBs/Food</DBDirectory>
<!--DBDirectory>/home/user/DBs/Wine</DBDirectory-->
<!--DBDirectory>/home/user/DBs/Cactus</DBDirectory-->
<!--DBDirectory>/home/user/DBs/Flower</DBDirectory-->
...
</Configuration>

Je pense 'template' et je l'écrirai plutôt sous la forme:

<Configuration>
...
<DBDirectory>${ x.get_DBdirectory() }</DBDirectory>
...
</Configuration>

Qu'en pensez vous?
- W

[thelvin]

Ben ouais, quelque chose de ce genre, moi aussi. En général c'est disponible, et puis XSLT le permet.

[epeios]

Ben, tu pourrais formaliser la même chose assez facilement en XQuery mais ça a l'inconvénient de ne plus être du XML.

En effet, quitte à manipuler du XML, autant que ce soit avec du XML.

Et avec XProc tu peux avoir tes documents sources "inline" et donc dans un même document XML définir donnée et transformation à appliquer.

Intéressant. Néanmoins, je suppose, à tort peut-être, que ça doit être beaucoup plus intrusif qu'avec 'XPP', c'est-à-dire que les transformations à appliquer au document XML à manipuler doivent être beaucoup plus lourdes.

Avec XSL-T (et sans doute plus facilement en XSL-T 2.0), on devrait pouvoir même définir dans une feuille de style générique les traitements que font ton programme actuel pour traiter ta grammaire "xpp".

Je connais assez bien XSL, et je serais curieux de voir ce que ça donnerais; peut-être qu'un jour j'essayerais de développer une telle feuille de style. Néanmoins, ce n'est qu'une manière parmi d'autres d'implémenter ce préprocesseur, sa grammaire restant à définir.

Je ne saisis pas bien ce que tu entends par "instructions définies pas cette normes doivent être placées dans un fichier dédié".

Cela signifie que, à l'instar de XSLT, on a, d'une part, un ou plusieurs fichiers contenant les données à manipuler, et, d'autre part, un ou plusieurs fichiers détaillant les manipulations à effectuer (l'équivalent des feuilles de styles en XSL). Mais cette assertion est apparemment caduque vu ta remarque ci-dessus concernant les documents 'inline'.

Oui, bof. Chacun son truc, je suppose.

Voilà sans doute la clef de l'intérêt de 'XPP'. Sa mise en œuvre paraîtra sans doute beaucoup plus naturelle et intuitive à un développeur C/C++, familiarisé avec la notion de préprocesseur de par sa mise en œuvre systématique dans ses sources, qu'à un développeur JAVA (par exemple), qui utilise un langage qui ne fait pas usage d'un préprocesseur (du moins était-ce le cas la dernière fois que j'ai développé en JAVA ...).

Solutions similaires tout aussi pratiques sans création de processus de ce genre :

- Avoir un fichier final pour chaque configuration possible, et copier celui qu'on veut vers le nom du fichier qui sera effectivement lu par l'application.

La macro donnée en exemple n'est qu'une parmi plusieurs autres. S'il fallait un fichier pour chaque combinaison possible de valeurs de ces macros, il en faudrait plusieurs dizaines au bas mots, ce qui est loin d'être pratique !

- En général les configs et données XML sont éclatables en plusieurs fichiers, soit qui se référencent les uns les autres, soit qu'on choisit de référencer dans la ligne de commande ou autre option. Éclater les différentes confs en différents fichiers et référencer ceux qu'on veut et pas les autres.

A charge pour chaque logiciel d'implémenter un mécanisme permettant ce référencement de fichiers, ce qui fait qu'on risque d'avoir autant de mécanismes que de logiciels ayant besoin d'un tel mécanisme. Si c'est tellement courant, autant normaliser ce mécanisme et proposer des outils standards pour le mettre en œuvre (ce qui est le cas à ma modeste échelle, chacune des mes applications ayant besoin d'un fichier de configuration, ou, plus largement, manipulant des fichiers XML, profitant automatiquement du préprocesseur 'XPP').

L'exemple est un peu trop trivial pour me convaincre... Sans compter que le faire à coup de XSLT évite d'inventer son propre format et n'est pas plus contraignant. Écrire une nouvelle XSLT*à chaque fois ne me semble pas beaucoup plus compliqué qu'écrire de nouveaux xpp à chaque fois.

Un exemple se doit d'être un peu trivial pour être clair, non ? En tout cas, pour être trivial, l'exemple n'en est pas moins tiré d'un de mes fichiers de configurations que j'utilise quotidiennement. Sinon, j'ai également un fichier de configuration de plus de 5000 lignes avec plus de 1000 directive 'XPP'; je crois qu'à cette échelle, on ne peut plus parler de trivialité !

Au risque de me répéter, XSLT (que je connais bien, et que j'ai donc écarté en connaissance de cause) est plus contraignant dans la mesure ou l'on est obligé d'avoir au moins deux fichiers, l'un contenant les données à manipuler, et l'autre la manipulation à réaliser

Salut,

Je ne fais que passer et je n'ai qu'un bout de doigt de pied dans XML.
Lorsque, je vois cela:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
 <Configuration>
...
<!--DBDirectory>/home/user/DBs/Test</DBDirectory-->
<DBDirectory>/home/user/DBs/Food</DBDirectory>
<!--DBDirectory>/home/user/DBs/Wine</DBDirectory-->
<!--DBDirectory>/home/user/DBs/Cactus</DBDirectory-->
<!--DBDirectory>/home/user/DBs/Flower</DBDirectory-->
...
</Configuration>

Je pense 'template' et je l'écrirai plutôt sous la forme:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
 <Configuration>
...
<DBDirectory>${ x.get_DBdirectory() }</DBDirectory>
...
</Configuration>

Qu'en pensez vous?
- W

Et comment définit-on les différentes valeurs que peut contenir la balise 'DBDirectory' ? Et de manière plus générale, de quel 'langage' s'agit-il ?

Ben ouais, quelque chose de ce genre, moi aussi. En général c'est disponible, et puis XSLT le permet.

cf plus haut concernant XSLT.

[wiztricks]

Salut

Et comment définit-on les différentes valeurs que peut contenir la balise 'DBDirectory' ? Et de manière plus générale, de quel 'langage' s'agit-il ?

L'idée de base est d'utiliser des outils qui existent déjà pour par exemple la construction de page Web dynamiques ou le préformatage du code dans un IDE par exemple - c'est le "moteur" de template -.

Comme un certain nombre d'items du contenu sont calculés dynamiquement, un moteur de template appelle des fonctions retournent ce qu'on veut et seront écrites dans un langage évolué.

Après c'est selon vos goûts: Freemarker/Java, TagLib/PHP, Genshi/Python, Perl Template Toolkit/Perl,...

La syntaxe d'un moteur de template est simple à acquérir, une expérience dans un langage de programmation probablement plus "structurante" côté choix. Cela vous permet aussi d'avoir des ouvertures côté bases de données pour récupérer et stocker certaines informations.

Regardez ce que sait déjà faire par exemple FreeMarker.
- W

[epeios]

C'est en effet une solution dans le cadre de logiciels faisant déjà usage de ce type d'outils, mais pour des programmes de type console, de tels outils ne peuvent, je pense, entrer en ligne de compte ...

[wiztricks]

Salut,

C'est en effet une solution dans le cadre de logiciels faisant déjà usage de ce type d'outils, mais pour des programmes de type console, de tels outils ne peuvent, je pense, entrer en ligne de compte ...

Je n'ai peut être pas compris votre remarque mais il s'agit de bibliothèques.
Que l'application qui les utilise soit lancée en mode console ou autre n'a pas grande incidence (sur leur mise en œuvre).
Qu'en pensez vous?
- W

[epeios]

Je n'ai peut être pas compris votre remarque mais il s'agit de bibliothèques.
Que l'application qui les utilise soit lancée en mode console ou autre n'a pas grande incidence (sur leur mise en œuvre).

Dans les exemples de moteurs que vous citez, les langages utilisés rendent difficiles leur intégration avec mes logiciels, ces derniers étant codés en C/C++ (il est vrai que c'est ce dernier point, que j'avais omis de préciser, qui rend leur mise en œuvre difficile plus que la nature de l'application).

Il faudrait donc des bibliothèques similaires, mais codées en C ou C++ (ce n'est certes pas indispensable, mais un autre langage, surtout s'il n'est pas compilé, compliquerait considérablement leur mise en œuvre), et d'une taille raisonnable par rapport à la taille des applications (qui est de l'ordre du Mo pour celles du type console) dans lesquelles elles seront intégrées, pour que je puisse en avoir l'usage.
Si de telles bibliothèques existent, elles peuvent effectivement présenter une solution intéressante ...

[wiztricks]

Salut

C/C++ ne sont pas forcément des langages très utilisés pour faire des applications Web alors côté moteurs de template, ils sont moins riches que PHP . Ceci dit ils se réveillent un peu avec Wt.

Il faut chercher un peu pour voir ce qui (vous) conviendrait le mieux mais pour l'instant j'ai trouvé cela http://code.google.com/p/google-ctemplate/

(ce n'est certes pas indispensable, mais un autre langage, surtout s'il n'est pas compilé, compliquerait considérablement leur mise en œuvre), et d'une taille raisonnable par rapport à la taille des applications (qui est de l'ordre du Mo pour celles du type console) dans lesquelles elles seront intégrées, pour que je puisse en avoir l'usage.

En quoi un langage pas compilé "compliquerait" la mise en oeuvre? J'entends que çà irait beaucoup moins vite mais est ce de la mise en oeuvre?

Je suis assez surpris par les exigences que vous formulez côté taille des exécutables: çà fait un certain temps que le développeur moyen vit sans trop s'en préoccuper et c'est rarement dramatique.
- W

[epeios]

C/C++ ne sont pas forcément des langages très utilisés pour faire des applications Web alors côté moteurs de template, ils sont moins riches que PHP . Ceci dit ils se réveillent un peu avec Wt.

L'application WEB sur laquelle je travaille est justement codée en C/C++ ! Mais du fait que je n'utilise pas PHP (car inadapté pour l'application en question), je n'avais qu'une connaissance très parcellaire de ces moteurs de templates codés en PHP.

Il faut chercher un peu pour voir ce qui (vous) conviendrait le mieux mais pour l'instant j'ai trouvé cela http://code.google.com/p/google-ctemplate/

Effectivement, des outils de ce type, bien qu'ayant une approche différente de celle que j'ai adoptée, aurait pu constituer une solution intéressante.

En quoi un langage pas compilé "compliquerait" la mise en oeuvre? J'entends que çà irait beaucoup moins vite mais est ce de la mise en oeuvre?

'Mise en œuvre' n'est peut-être pas l'expression adéquate. Actuellement, le cœur de mes applications est uniquement constitué d'exécutables, et/ou de bibliothèques dynamiques, simples à mettre en place. Avec un langage interprété, il faudrait, en plus, l'ajout de sources + un interpréteur, voire installer une machine virtuelle. Et pour tout dire, c'est (surtout) aussi parce que, moins j'ai affaire à des langages interprétés, mieux je me porte .

Je suis assez surpris par les exigences que vous formulez côté taille des exécutables: çà fait un certain temps que le développeur moyen vit sans trop s'en préoccuper et c'est rarement dramatique.

Mes exécutables et bibliothèques dynamiques ont généralement une taille de l'ordre du Mo (tout compris, car ils ne nécessitent pas l'installation de bibliothèques dynamiques tierces). Faciles à transmettre par mail (entre autres avantages). Ça me dérangerait des les voir prendre un embonpoint pouvant se révéler plus ou moins gênant juste pour leur ajouter une fonctionnalité n'ayant rien d'essentielle à leur fonctionnement ...

Je clos le fil puisque, grâce à vos réponses, pour lesquelles je remercie tous les intervenants, j'ai un bon aperçu des méthodes et technologies employés pour répondre à la problématique à l'origine de cette discussion.