Discussion :

[jfouche]

Bonjour

Pour un projet sur lequel je travail, je doit pouvoir effectuer les opérations suivantes :
- Charger un modèle de fichier XML (c'est un fichier XML)
- Effectuer quelques modifications
- Pouvoir l'enregistrer à un endroit donné.

Le problème que je rencontre vient du fait que mon application (sous Windows) manipule un fichier qui doit être utilisé sous LINUX, et dont la DTD doit être en chemin absolu. Cette DTD doit être absolument être présente dans le fichier générer, conformément à ce qui est présent dans le modèle XML. Je ne peux pas préjuger du contenu de ce modèle.

Si j'effectue les opérations suivantes :

Code :

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

1
2
3
4
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setValidating(false);
DocumentBuilder builder = factory.newDocumentBuilder();
Document doc = builder.parse(file);

le parser se plaint comme quoi il ne trouve pas la DTD (setValidating(false) n'a pas l'air de faire ce que je souhaite).

Je peux obtenir un parsing correct en ajoutant ceci :

Code :

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

1
2
3
4
5
6
7
8
builder.setEntityResolver(new EntityResolver()
{
    @Override
    public InputSource resolveEntity(String publicId, String systemId) throws SAXException, IOException
    {
        return new InputSource(new java.io.StringReader(""));
    }
});

avant le parse. Oui mais... je perd la DTD lors de la sauvegarde de mon document.

Voyez vous une solution ?

[tchize_]

1) a quoi ressemble le doc de départ
2) à quoi ressemble le doc d'arrivée que t'obtiens
3) que devrais-tu obtenir
4) quel est ton code de chargement / modification / sauvegarde (on n'a que le chargement là)

[thelvin]

le parser se plaint comme quoi il ne trouve pas la DTD (setValidating(false) n'a pas l'air de faire ce que je souhaite).

Ça fait, littéralement, ce que ça dit que ça fait. Ça dit qu'il ne faut pas valider.
Si tu dis à ton enfant de ne pas aller mettre le désordre au salon. Tu ne lui as rien dit sur le fait d'aller au salon : il y va, il y va pas, c'est son problème. En tout cas, qu'il y aille ou pas, il a ordre formel de ne pas le mettre en désordre.
C'est pareil avec le parseur XML. Tu lui as dit de ne pas valider, à tes ordres, il ne validera pas. Quoi ? Ne pas aller lire la DTD ? Personne ne m'a parlé de ça.

Explication : validation ou pas, la DTD pourrait contenir des définitions d'entités internes (ou externes, d'ailleurs). Il ne sait pas s'il y en a, mais s'il y en a il les lui faut. Donc il va les chercher. Ça n'a rien à voir avec la validation, qui est rappelons-le, la vérification que le document respecte une grammaire annoncée.
Il me semble qu'on peut lui dire de ne pas chercher à aller voir la DTD, mais je ne sais plus comment. Ça a à voir avec http://apache.org/xml/features/nonvalidating/load-external-dtd, trouvable ici : http://xerces.apache.org/xerces-j/features.html

Oui mais... je perd la DTD lors de la sauvegarde de mon document.

Rien à voir avec EntityResolver. Il ne touche pas au DOCTYPE annoncé par le fichier. Le problème est ailleurs.
Notamment, la bonne vieille technique de sérialiser le Document avec un Transformer, efface toujours le doctype. L'une des nombreuses raisons pour lesquelles j'utilise plutôt JDOM.

[tchize_]

Je rajoute qu'une DTD c'est une forme basique d'inclusion de définitions dans un document xml. Le transformer peux très bien prendre le contenu de la DTD et l'inclure telle quelle dans le document final plutot que de mettre un lien vers un document DTD.

[jfouche]

Thelvin, merci beaucoup pour les explications, c'est plus clair pour moi.

Le problème est ailleurs.
Notamment, la bonne vieille technique de sérialiser le Document avec un Transformer, efface toujours le doctype.

Bah voila, c'est ce que je fais...

L'une des nombreuses raisons pour lesquelles j'utilise plutôt JDOM.

Par contre, j'essaie de limiter au max le nombre de COTS pour mon produit, et j'aurai préféré une solution qui n'utilise pas une bibliotheque externe. J'ai rajouté le doctype récupérée avec l'EntityResolver au transformer, mais ça ne me parait pas terrible comme solution. En plus, ça rajoute file: au chemin de la DTD, ce que je n'ai pas testé avec le soft linux.

PS : Le lien fourni ne marche pas...

[tchize_]

si vous voulez convertir le url en nom de fichier , faites un

Code :

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

new File(new URL(ligne).toURI())

[jfouche]

Je fais ça :

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
Source source = new DOMSource(this.doc);
File file = new File(filename);
Result result = new StreamResult(file);
try
{
	Transformer xformer = TransformerFactory.newInstance().newTransformer();
	if (this.systemDTD != null)
	{
		xformer.setOutputProperty(OutputKeys.DOCTYPE_SYSTEM, this.systemDTD);
	}
	xformer.transform(source, result);
}
catch (Exception e)
{
	e.printStackTrace();
	return false;
}

Difficile de proposer une conversion...

[thelvin]

Utilise plutôt doc.getDocType().getSystemId(), inutile de chercher midi à quatorze heures.
Attention quand même, getDoctype() renvoie null pour les documents qui n'ont pas de doctype.

Par contre, j'essaie de limiter au max le nombre de COTS pour mon produit, et j'aurai préféré une solution qui n'utilise pas une bibliotheque externe.

En Java ??! Non, non, je ne juge pas, chacun ses petits masochismes...

PS : Le lien fourni ne marche pas...

Quoi, http://xerces.apache.org/xerces-j/features.html ?
Il marche maintenant, le serveur devait être down.

[jfouche]

Par contre, j'essaie de limiter au max le nombre de COTS pour mon produit, et j'aurai préféré une solution qui n'utilise pas une bibliotheque externe.

En Java ??! Non, non, je ne juge pas, chacun ses petits masochismes...

C'est plutôt qu'on a du envoyer au client la liste des COTS utilisé sur notre produit. Changer cette liste maintenant a un coût. De plus, nous passons un peu de temps à faire une analyse juridique des COTS que nous utilisons, et ça aussi a un coût (financier et temps).
D'où ma recherche d'une solution sans COTS aujourd'hui. Par contre, nous utilisons bien plusieurs COTS sur notre produit (je ne refais pas qqchose qui existe...). Certains open sources, et d'autres achetés (ex : JIDE, que je conseil pour le rapport qualité / suivi / coût).

Utilise plutôt doc.getDocType().getSystemId(), inutile de chercher midi à quatorze heures.

Ca cartonne, en mieux que ce que j'avais : cela ne préfixe pas par file:

[tchize_]

Il doit être magique votre chef de projet, si il sait avant le développement de quelles librairies vous allez avoir besoin