Je veux faire un générateur de News du type PHPNuke, en JSP/Servlet/XML.
J'ai une BD qui stocke la structure logique de mes documents : genre, une News est caractérisée par une source(entité, un docmaster, une date d'émission, une date d'update) et un contenu (titre, images et paragraphes).
Donc les documents que je génère peuvent être de toutes sortes : News, Info techniques, liste de fournisseurs...
Et en sortie, je génère le XML correspondant.
Ici :  
<news>
  <source>
    <entite>...</entite>
    <docmaster>...</docmaster>
    <date_emission>...</date_emission>
    </date_update>...</date_update>
  </source>
  <contenu>
    <titre>...</titre>
    <paragraphe>
       <image>...</image>
       <texte>...</texte>
    </paragraphe>
  </contenu>
</news>
les champs entite, docmaster, date_emission, date_update... sont automatiquement renseignés lorsque l'auteur se logue (on récupère l'entité du docmaster à partir d'un annuaire LDAP en suivant le cycle de validation dont il dépend)
Le reste est rempli via un formulaire web.
Que pensez vous de ça ? Du coup, plus besoin de DTD et le docmaster n'a pas à connaitre le XML. En revanche, le webmaster peut à volonté créer de nouveaux type de documents en combinants les différents champs existants ou en créer d'autres.
Ces champs sont définis par des type de données contrôlés par des javascript scpécifique inscrits dans la base de données. Du coups, en composant les types de documents, on ne se soucie pas des contrôles à effectuer lors de la saisie des formulaires.
Par contre, quelle est la meilleure solution en sortie ?
Ecrire en dur les fichiers XML généré ou bien générer un XML transitoire qu'on envoie à une JSP pour afficher le HTML ?
La première solution est plus légère pour l'utilisateur puisqu'en consultation on n'utilise pas le SGBD. Par contre, il est nécessaire de créer des XSL pour compiler les news au sein d'une page par exemple. La deuxième solution est plus lourde puisque chaque page XML est recomposée à partie de la BD, mais pas besoin de XSL pour assembler les news, juste une requête, le XSL ne sert qu'à la présentation graphique.
...désolé si je ne suis pas clair, je débute en XML

Beuh alors ?
C'est idiot ou c'est bien ?

pour un débutant ca a l'air qd meme poussé mais je t'avouerai que ca fait bcp de concepts a capter en un seul coup

je suis débutant (en XML seulement), mais je me suis beaucoup renseigné sur le sujet. En fait, je suis pas débutant en programmation, mais c'est le concept du XML qui m'intrigue... J'ai mis un certain temps à me rendre compte de sa puissance.  
Je me suis longtemps posé la question du "à quel moment" on utlise XML.
Tel que je l'utilise, le XML se retrouve en bout de chaîne. En fait, j'utilise une architecture multi-tiers classique, sauf qu'au lieu de générer du HTML, comme beaucoup d'applications du type PHPNuke ou DaCode le font, je génère du XML. Le XML permettant de générer ses balises, j'ai un document final enrichi au niveau des données : je sais tout ce qu'il fait sur mon document : l'auteur, la date... de plus, la catégorie à laquelle appartient l'info est déduite du sous ensemble dans lequel l'auteur publie et du département auquel il appartient (si il travaille dans le département informatique, le document appartient à la catégore informatique) + d'autres infos sur la catégorie que l'auteur renseigne lui même.  
J'ai un CSS global qui contrôle les paramètres d'affichage de tout l'Intranet + des CSS et XSL appliqués à chaque groupe de document. Du coups,il est très facile de changer l'interface graphique du site en entier en retoucher les templates de chaque niveau (la créaton de templates en XSL est très simple).
De plus, j'ai créé une balise spéciale pour JSP qui génère automatiquement el fichier HTML correspondant en associant le XML à son XSL.
Au final, j'ai un site qui est mis à jour et enrichi via ne interface web de manière très simple par toute personne autorisée (elle choisit son modèle de publication : news, info technique...). Il est très facile de créer de nouveau mdèle en combinant les champs existant. On peut créer de nouveau champs... et on associer les groupes de publication à des XSL pour l'affichage. Chaque groupe a au moins 2 XSL associé : un XSL pour l'affichage en lecture HTML, l'autre en écriture... et autant d'autre pour tout type d'affichage (impression, wap...) en sachant que chaque XSL ne nécessite que peu de changement pour s'adapter aux différents formats.
 
Ce qui m'intrigue, c'est que ça marche super bien, c'est très évolutif et que c'est pas dur à programmer... ou est le problème ?

Est_il possible de faire une appli de ce type en 100% XML, en s'affranchissant du SGBD relationnel ?
A quoi sert une DTD si on peut la remplacer par ce type de structure : SGBD+XML ?

up

moi j'en dis juste que je doute que ça soit aussi performant qu'un systeme basé sur un sgbdr. je crois que l'xml devrait etre utilisé slt dans le cadre d'échange d'infos entre applications...

C'est ce que je pense aussi... mais j'ai peur d'avoir tort et de ne pas voir la portée réelle du XML...
J'ai un peu de mal à comprendre, mais j'ai vu un collègue développer un truc dans le genre tout en XML et Java, ça a l'air de bien tourner... et puis, si XML ne servait qu'à l'échange des données, pourquoi tout ce raffut autour de cette technologie ?

Au fait, quelqu'un connait_il un Content Management System basé sur XML ?
Apparemment, la plupart des CMS existant sont à base de PHP/MySQL. En connaissez vous en JSP/Servlet.
Quelqu'un utilise_t_il dans son entreprise un CMS du marché ?

Quelqu'un a_t_il déjà utilisé Cocoon ?
 
http://xml.apache.org/cocoon/index.html

Bon, une dernière question...  
Que vaut_il mieux ?
Stocker les données XML dans la base de donnée :
par exemple dans une table : Id/type/XML
dans ce cas : 1/news/
<news>  
 <source>  
   <entite>...</entite>  
   <docmaster>...</docmaster>  
   <date_emission>...</date_emission>  
   </date_update>...</date_update>  
 </source>  
 <contenu>  
   <titre>...</titre>  
   <paragraphe>  
      <image>...</image>  
      <texte>...</texte>  
   </paragraphe>  
 </contenu>  
</news>  
 
ou bien stocker le chemin du xml généré :
1/news/htpp://...news_01.xml
 
dans le premier cas, pour avoir toutes les news générées par une entité par exemple, je fais une requête et je génére le XML correspondant comme une simple concaténation des différents XML, dans le deuxième cas, je génère un XML compilant les news par XSL...
Dans les deux cas, je peux retoucher les XML en les parsant de la même manière.
 
Bref, j'aimerai savoir ce qui est le plus efficace en terme de rapidité et de simplicité (moteur de recherche...etc).
Quelqu'un connait_il des articles sympa traitant du couple XML/SGBD. On trouve souvent des exemples de XML très simples... Mais qu'en est il du stockage ?
Promis, après ça j'arrête...

Pour ceux que ça intéresse, un super tutorial JSP/XML
 
http://www.jspinsider.com/tutorial [...] Chap12.pdf

encore moi, toujours en quête de la meilleure solution pour combienr BD et XML sans forcément devoir acquérir une BD native XML :
 
si je reprendre mon exemple de news
 
<news>
 <source>
   <entite>...</entite>
   <docmaster>...</docmaster>
   <date_emission>...</date_emission>
   </date_update>...</date_update>
 </source>
 <contenu>
   <titre>...</titre>
   <paragraphe>
      <image>...</image>
      <texte>...</texte>
   </paragraphe>
 </contenu>
</news>
 
pourqui ne pas séparer un XML en plusieurs parties ? Une partie adaptées à la structure arborescente du XML, typiqement :
 
 <contenu>
   <titre>...</titre>
   <paragraphe>
      <image>...</image>
      <texte>...</texte>
   </paragraphe>
 </contenu>
 
et une autre partie plus adaptées au relationnel :
 
 <source>
   <entite>...</entite>
   <docmaster>...</docmaster>
   <date_emission>...</date_emission>
   </date_update>...</date_update>
 </source>
 
Par exemple, je créé une table News, avec les attribut IdNews, XMLNews, dateEmission, dateUpdate... et toutes les clés étrangères vers les tables me permettant d'identifier l'origine de la news, donc qui pointent vers les tables Utilisateur, Entités...etc
Je stockerais alors le contenu XML tel quel dans la colonne XMLNews.
Ainsi, je peux recomposer facilement un fichier XML en sortie en limitant les jointures (créer une structure relationnelle telle que celle des News en XML par exemple aurait été trop cmplexe pour rien).  
Donc je recompose en sortie, très simplement le XML des News appartenant à telle ou telle entité :
<lesNews entite="comptabilite"...>
<news auteur="bidule" dateEmission="11/03/2002"...>
 <contenu>
   <titre>...</titre>
   <paragraphe>
      <image>...</image>
      <texte>...</texte>
   </paragraphe>
  <paragraphe>
      <texte>...</texte>
   </paragraphe>
 </contenu>
</news>
<news news auteur="machin" dateEmission="12/04/2002"...>
 <contenu>
   <titre>...</titre>
   <paragraphe>
      <image>...</image>
      <texte>...</texte>
   </paragraphe>
 </contenu>
</news>
</lesNews>
 
Du coups, je peux stocker les XML et je profite des mécanismes de la BD pour recomposer mes XML de manière dynamique, en sortie, j'applique des XSL, eux même stockés dans la BD et qui sont donc paramétrables facilement.
Ca, c'est en consultation.
En modification, je profite de la BD pour vérifier les droits...etc
et j'extrait simplement le XML à la demande de son auteur, par exemple, celui ci le modifie très facilement en travaillant sur le XML (soit directement, soit via une couche WYSIWIG), à la fin, y a plus qu'a mettre à jour la BD avec le nouveau contenu.
 
Ca m'a l'air simple et rapide !
 
Vous en pensez quoi ?
Sérieux, j'aimerai quelques réactions !  

moi ce qui me dérange c'est ton idée de vouloir "séparer" le document XML. Selon moi un document XML décrit des données point barre. Rien d'autre.
 
mais bon c'est que mon avis hein

DarkLord a écrit a écrit : moi ce qui me dérange c'est ton idée de vouloir "séparer" le document XML. Selon moi un document XML décrit des données point barre. Rien d'autre.   mais bon c'est que mon avis hein

 
ce qui te dérange, c'est que je sépare les données ?
Mais au final, je ne les sépare pas, mais je les assemble. Je sais, la nuance est faible, mais si tu regarde bien :
 
<contenu>  
  <titre>...</titre>  
  <paragraphe>  
     <image>...</image>  
     <texte>...</texte>  
  </paragraphe>  
</contenu>  
 
et
 
<source>  
  <entite>...</entite>  
  <docmaster>...</docmaster>  
  <date_emission>...</date_emission>  
  </date_update>...</date_update>  
</source>  
 
pourrait tout à fait être des XML autonomes
 
Ce qui est fait lorsqu'on utilise pas une BD, c'est que ces XML sont stockés en tant que fichiers texte et qu'il faut à chaque fois les recomposer via XSL en un nouveau XML pour pouvoir faire des requêtes...etc
 
Au final, c'est pareil, sauf qu'au lieu de les recomposer via XSL, je les recompose via SQL et je profite de la rapidité des BD.
 
D'un autre côté, au lien d'avoir de fichiers indépedant, j'aurait pu choisir d'avoir des gros blocs contenant toutes les news, comme
 
<lesNews>
<news>  
 <source>  
   <entite>...</entite>  
   <docmaster>...</docmaster>  
   <date_emission>...</date_emission>  
   </date_update>...</date_update>  
 </source>  
 <contenu>  
   <titre>...</titre>  
   <paragraphe>  
      <image>...</image>  
      <texte>...</texte>  
   </paragraphe>  
 </contenu>  
</news>  
.
.
.
<news>  
 <source>  
   <entite>...</entite>  
   <docmaster>...</docmaster>  
   <date_emission>...</date_emission>  
   </date_update>...</date_update>  
 </source>  
 <contenu>  
   <titre>...</titre>  
   <paragraphe>  
      <image>...</image>  
      <texte>...</texte>  
   </paragraphe>  
 </contenu>  
</news>  
</lesNews>
 
et là, à chaque fois que tu veux une info, tu te recharge le fichier en entier ?
 
Au final, la solution XML + BD sera plus rapide, tout en profitant des possibilités de XML, puisqu'en mise à jour, tu peux vérifier tes données via DTD ou XSD et tu peux générer des fichiers XML pour les transmettre si t'en a envie.

apparemment un gars sur un autre forum va dans le même sens :
 
(petit détail d'anglais, RDBMS veut dire SGBDR)
 
"I work at Microsoft, and tend to hear a lot of these descriptions at work. Mostly there are the xml purists on one side, and the rdbms fans on the other. It's already quite easy to integrate the two, if you think about the possibilities. First you could store xml document in MS SQL 2000 Server as big "BLOBS" OF xml, then output the blobs as needed on basis of sql or xpath queries. On, say, a web server, transform the xml document to appropriate xhtml output,using xsl, and this can be handled by recent browsers.
This doesn't seem too hard, and seems to allow you some of the powerful advantages of both. On another thought, if you want to integrate data from almost any disparate systems, it may be the easiest to output the data to XML, or to a form that another transform could convert to XML, and again with SQL 2000, you can pass valid xml in directly to a table."

Une vraie mine d'or le site d'IBM
 
--> "Don't use XML for searching
XML documents (by themselves) are not well suited to being searched. Because they're just flat text, any of XML's native searching mechanisms (such as XPath) must parse the entire document (or documents) to locate the piece (or pieces) you're interested in. If you're trying to work with that single document with information about seven million customers, searching would be extremely inefficient. If you break the document up into smaller documents -- say, one per customer -- the problem still occurs: To find the particular customer you're looking for, you need to parse each document until you find the appropriate one. The only good solution for searching XML documents is to introduce some sort of indexing mechanism -- either a relational database index or some sort of native XML indexing tool -- that significantly reduces the amount of information that has to be processed to locate the document (or document fragment) you're interested in. When you have data-oriented information (as opposed to text-oriented information such as a book manuscript), a relational database is well suited for this task, and it provides other benefits, as you'll see in the next tip."
 
--> "Don't use XML for summarization
Summarizing information stored in XML documents is also very inefficient. The native language provided by XPath contains only the bare minimum of aggregation functionality, and even this is not easily usable if the information you want to summarize is found in more than one document. Also, summarization presents the same problem as searching: Each document must be parsed to discover and extract the information being summarized. Again, I recommend indexing the information, thus reducing the amount of information to sift to discover the pieces that are being operated on. Alternatively, you could generate an additional document that contains summary information as detail XML documents are introduced into the system. However, that would not allow you to do ad hoc summarization, and it can be a bit of a management chore. For the best flexibility for summarization tasks, a relational database is really the only good choice; most off-the-shelf XML indexers do not expose the indexes themselves for direct programmatic manipulation."