Document Object Model



Publié dans news:fr.comp.lang.java (2003-06-07):
Bonjour,

J'aimerais savoir s'il existe des projets open source qui permettent de créer a partir d'un XSD, un document XML valide en lui proposant les balises adaptées. (genre ce que fait XML Spy)
Il y a pollo et gendoc. Comme par hasard ce sont deux projets Français -:)) . Voir les URL ici:
http://jmvanel.free.fr/Principales_sources_technologiques.htm

gendoc je ne sais pas encore, mais pollo n'utilise pas toute l'information du XSD, en gros il prend l'info. de type DTD.
Mieux, sous vous aviez des astuces à me donner pour réaliser un tel produit je suis tout ouie. J'aimerais mettre en memoire ce XSD et l'utiliser efficacement. J'hesite a passer par des objets ou par un document xml qui permettrait d'exploiter ce XSD.
Il y a un endroit dans le document XML Schema où mettre des infos à destination d'un programme c'est la balise appinfo; par exemple pour y mettre un libellé de formulaire, le nom d'une classe qui va valider la saisie, ou bien des contraintes en XPath, etc ... On peut mettre des appinfo à tous les niveaux d'un document XML Schema.

Une autre piste que je peux donner, c'est ceci:

Document Object Model (DOM) Level 3 Validation Specification
Version 1.0
W3C Working Draft 05 February 2003
http://www.w3.org/TR/2003/WD-DOM-Level-3-Val-20030205/validation.html

Pour donner le parfum de cette spec., voici l'interface principale :
interface NodeEditVAL {

  // CheckTypeVAL
  const unsigned short      WF_CHECK                       = 1;
  const unsigned short      NS_WF_CHECK                    = 2;
  const unsigned short      PARTIAL_VALIDITY_CHECK         = 3;
  const unsigned short      STRICT_VALIDITY_CHECK          = 4;

  readonly attribute DOMString       defaultValue;
  readonly attribute DOMStringList   enumeratedValues;
  boolean            canInsertBefore(in Node newChild, 
                                     in Node refChild);
  boolean            canRemoveChild(in Node oldChild);
  boolean            canReplaceChild(in Node newChild, 
                                     in Node oldChild);
  boolean            canAppendChild(in Node newChild);
  boolean            isNodeValid(in boolean deep, 
                                 in unsigned short wFValidityCheckLevel)
                                        raises(ExceptionVAL);
};

Ce n'est encore qu'un document de travail, mais c'est exactement ce dont les éditeurs XML ont besoin. Il y a une valeur ajoutée par rapport à l'accès "brut" à l'élément du Schema correspondant au noeud courant (ce que fait la Post Schema Validation Information de Xerces). Il n'y a encore aucune implémentation, mais certainement Xerces (et les autres) vont s'y mettre quand ce sera une recommandation. En attendant, il est bon de s'y conformer, même si on en fait une implémentation très partielle et spécifique. Ainsi le moment venu, on pourra brancher  une implémentation conforme.
Ce que DOM3 ne précise pas c'est comment instancier ces interfaces. Si c'est comme PSVI avec Xerces, on transtypera (cast) un noeud ordinaire vers l'interface NodeEditVAL. Si on veut utiliser tout de suite ces interfaces, sans présager de la façon d'instancier, on peut par exemple faire une fabrique avec une méthode :
NodeEditVAL createNodeEditVAL(Node n);
Publié dans news:fr.comp.lang.java (2003-06-01):
QQun pourrait me dire mais en résumé ce qu'est le design pattern FACTORY et
le principe de fonctionnement ?
car je trouve que des trucs longs et complexes, et rien de simple qui parle
du principe.
Quand on utilise des interfaces, c'est à dire un comportement pur
sans implémentation précise, on a besoin de créer (instancier comme on dit) des objets qui implémentent cette interface. Et alors si on parsème son code de "new MaClasse();", on perd le bénéfice d'avoir du code indépendant de toute implémentation (et dépendant seulement de l'interface).

C'est là que le modèle de conception "Fabrique" intervient. On écrit une  classe "FabriqueDeMonInterface" (ou MonInterfaceFactory) avec une méthode creerMonInterface() (ou createMonInterface(), ou newInstance() ) sans argument qui renvoie un objet répondant à cette interface.
La création effective d'un objet MaClasse (ou autre qui répond à l'interface MonInterface) est ainsi centralisée dans la fabrique.
Pour changer d'implémentation, il suffit donc de changer un seul endroit: la méthode FabriqueDeMonInterface.creerMonInterface().

Et c'est pour avoir cette souplesse (et non pas pour enbêter le dévelopeur) que avec JAXP on fait typiquement 3 lignes au lieu d'une pour digérer un fichier XML:

DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = factory.newDocumentBuilder();
org.w3c.dom.Document doc = builder.parse(URL);

Ainsi, si je veux pas l'implémentation par défaut de DOM, je n'ai qu'à faire préalablement ceci pour nommer l'implémentation:
System.setProperty(
"javax.xml.parsers.DocumentBuilderFactory",
"net.sf.saxon.om.DocumentBuilderFactoryImpl" );

Pareil pour serializer , en 2 mots ? moi je comprends ca commme quoi ca
"convertit" des informations d'un type dans un autr type.. c juste ?

Un serializer convertit un objet (par exemple un org.w3c.Document XML) en une chaîne de caractères ou un flot de sortie (OutputStream). En clair, à partir d'un XML en mémoire (ou résultant d'une série d'évènements SAX), le serializer crée le XML que nous voyons, avec ses balises. Il ne faut pas penser que soi même, vite fait sur le gaz, on va développer un serializer XML. Il ne suffit pas de faire:
out.println("<"+tag+">"+contenu);
parce que si la variable contenu contient un & , ou un <, ou un é alors que l'encodage est UTF-8, le XML ne sera pas bien formé.