Discussion :

[Maximil ian]

Bonjour,

Dans le cadre du déploiement d'un CMS dans ma boite, nous avons retenu XML comme format de stockage du contenu, ce qui apporte une souplesse en termes de publication sur différents supports (papier, CD-ROM, site Intranet et Internet...)

Les créateurs du contenu vont donc devoir saisir du XML.
Sachant qu'ils ont du mal même avec les applications bureautiques classiques, quelle serait la meilleure solution ? Un éditeur XML WYSIWYG ? OpenOffice avec un filtre d'export XML ?

Le document XML contiendrait des éléments de mise en forme très basiques : 2 ou 3 niveaux de titre, paragraphes, texte accentué ("gras")... plus éventuellement des tableaux.
Y-a-t'il une DTD qui permette de faire ça (DocBook ?) ou est-il préférable de déterminer ma propre DTD ?

d'avance pour vos conseils.

[virgul]

Salut,

Moi je te conseilerais Infopath

mais faut voir quelle sont vraiment tes besoins et surtout si vous avez office 2003 edition entreprise

Concernant la DTD il est préférable que tu la fasse toi-même car aucune autre ne correspondra exactement a ce que tu veux!

++

Thierry

[GrandFather]

Bonjour,

j'ai travaillé dans ma boîte sur le même type de projet, la publication sur un Intranet d'un document de + de 2500 pages, et la solution retenue a été :

- Edition du document avec OpenOffice
- Conversion du document OOo à notre schéma XML avec XSLT
- Publication avec Cocoon, framework de publication XML
- Le schéma adopté pour les fichiers XML est un sous-ensemble de Docbook, les DTD Docbook permettant de dériver une nouvelle DTD à partir d'elles sans toucher à leur code ; on est passé ainsi de 400 balises à 40...
- Le tout saupoudré d'un peu de Java pour lier l'ensemble

Le retour d'expérience que je peux t'en donner est le suivant :

- J'ai envisagé un moment de leur faire saisir directement du XML ; j'ai très vite abandonné l'idée...

- Les utilisateurs (qui ont un peu le même profil que les tiens... ) n'ont pas eu de soucis majeurs pour adopter OOo, sachant qu'ils n'ont bénéficié que d'une journée de formation

- Pour des raisons de volumétrie (+2500 pages) il n'a pas été possible de conserver un seul document monolithique, qui a donc été éclaté en 21 fichiers comportant chacun un chapitre. Ce qui nous a empéché d'utiliser les filtres d'exportation XSLT de OOo, car en traitant chaque chapitre isolément il n'était plus possible de résoudre les liens hypertextes inter-chapitres. La transformation XSLT se fait donc en dehors de OOo.

- Le format XML de OOo est bien documenté, mais recèle des pièges quand on veut traiter des mises en formes élaborées ; ainsi, traiter des tableaux sophistiqués (avec cellules fusionnées horizontalement et verticalement) s'est révélé trop complexe avec XSLT. Le problème a été résolu en écrivant en Java une extension à Xalan pour traiter spécifiquement les tableaux.

- Les mises en forme autorisées au départ étaient les suivantes :
- jusqu'à 10 niveaux de titre
- Paragraphes
- Paragraphes en texte pré-formaté (avec police non proportionnelle - très pratique pour créer simplement des équations avec fractions)
- Liens hypertexte intra et extra document
- Tableaux
- Listes numérotées et à puces
- termes d'index
Les utilisateurs ont très vite trouvé les mises en forme de base insuffisantes et ont demandé des enrichissements supplémentaires (mise en forme des paragraphes dans les tableaux, couleur des caractères, etc.)

[Maximil ian]

Moi je te conseilerais Infopath

mais faut voir quelle sont vraiment tes besoins et surtout si vous avez office 2003 edition entreprise

Je ne connaissais absolument pas ce produit (ou alors je l'avais zappé en pensant que ce n'était qu'un autre composant inutile d'Office)
Il a l'air de correspondre à nos besoins et on a Office Pro 2003... A creuser donc.

Le retour d'expérience que je peux t'en donner est le suivant :

- J'ai envisagé un moment de leur faire saisir directement du XML ; j'ai très vite abandonné l'idée...

Moi l'idée ne m'a même pas effleuré (quand je vois le niveau de certains utilisateurs)

[...]
- Le format XML de OOo est bien documenté, mais recèle des pièges quand on veut traiter des mises en formes élaborées ; ainsi, traiter des tableaux sophistiqués (avec cellules fusionnées horizontalement et verticalement) s'est révélé trop complexe avec XSLT. Le problème a été résolu en écrivant en Java une extension à Xalan pour traiter spécifiquement les tableaux.

Je vois, le choix d'Open Office implique donc quelques complications...

- Les mises en forme autorisées au départ étaient les suivantes :
- jusqu'à 10 niveaux de titre
- Paragraphes
- Paragraphes en texte pré-formaté (avec police non proportionnelle - très pratique pour créer simplement des équations avec fractions)
- Liens hypertexte intra et extra document
- Tableaux
- Listes numérotées et à puces
- termes d'index
Les utilisateurs ont très vite trouvé les mises en forme de base insuffisantes et ont demandé des enrichissements supplémentaires (mise en forme des paragraphes dans les tableaux, couleur des caractères, etc.)

OK, c'est toujours bon à savoir. Merci pour ce retour d'expérience instructif en tout cas

[GrandFather]

Je vois, le choix d'Open Office implique donc quelques complications...

Je vais être un peu plus précis à ce sujet.

Il était possible de gérer les tableaux OOo uniquement avec XSLT, mais le code résultant aurait été assez long et complexe, donc pas facile à maintenir. J'ai donc trouvé plus pratique de traiter le problème avec Java. Mais il est possible que je me sois fourvoyé, et qu'une solution XSLT plus simple que la mienne existe.

D'autre part, je ne suis pas sûr que le schéma XML des fichiers Office, que je ne connais pas, soit beaucoup plus simple à transformer... Je te conseille en conséquence d'évaluer les deux schemas, et de retenir celui qui sera le plus "malléable" et adapté à tes besoins.

[Maximil ian]

D'autre part, je ne suis pas sûr que le schéma XML des fichiers Office, que je ne connais pas, soit beaucoup plus simple à transformer... Je te conseille en conséquence d'évaluer les deux schemas, et de retenir celui qui sera le plus "malléable" et adapté à tes besoins.

OK, merci

Virgul => peux-tu m'en dire un peu plus sur ton expérience avec infopath ? Est-ce que tu sais si on peut instancier un formulaire infopath avec des données provenant d'un document XML (par exemple si on veut modifier du contenu déjà existant) ?

[virgul]

A voir ce que tu dit sur tes utilisateur infopath serait l'outil idéal

Virgul => peux-tu m'en dire un peu plus sur ton expérience avec infopath ? Est-ce que tu sais si on peut instancier un formulaire infopath avec des données provenant d'un document XML (par exemple si on veut modifier du contenu déjà existant) ?

Oui on peux tout a fait récupérer des données xml dans un infopath moyennant quelque modif du xml(ajouter la PI d'infopath)!!

Infopath ouvre a mon avis une grande porte car il permet de travailler avec du .Net (plugin pour visual studio prog en C#, VB.net) et intégre a merveille le webservice et tu peux aussi intérroger directement des Bdd faire du conditionnal formatting très avancé définir des règle organiser des workflow avec biztalk si tu connais bref presque tout

Et si t'as pas trop .Net tu peux programmer en JScript ou en VBscript!!!

et après il te renvoit toute tes info en xml comme tu le décide!!!

Seul petit problème infopath est un nouveau produit qui dit nouveau produit dit quelque petit bug au niveau de l'affichage Wysiwig quand tu est en mode design.

Bref moi je le trouve génial si tes utilisateurs on office sur leur postes

Pour en savoir plus en général : www.infopathdev.com

Si t'as encore des questions pas de problème!!!

++

Thierry

[Maximil ian]

Bon, après quelques petits tests je pense qu'on va retenir Infopath qui est à la fois user friendly (ils ne seront pas trop dépaysés par rapport à Word...) et puissant dans ses fonctionnalités.

En revanche un point me chagrine, j'avais pensé alimenter le CMS via des Web Services (l'envoi vers un Web Service est proposé de base par InfoPath) mais je bute sur le fait que ça doit être un service en mode document/literal et non pas RPC/encoded. Or j'ai toutes les peines du monde à faire fonctionner mon serveur SOAP (en PHP) en document/literal...

Virgul, quelle connexion de données utilises-tu pour envoyer tes formulaires InfoPath ? Un service web ? Une base de données ? Un portail SharePoint ?

[virgul]

Salut,

Tant mieux faut que y en aie des gens qui s'y mettent a ce programme!!!
Pour qu'il puisse m'aider


Non en ce qui concerne les webservice moi j'utilise que ca avec deux trois xml externe et bientot une intégration sharepoint. Car avec les bdd tu les expose en front-end et mon boss ne voudrais pas trop! résultat on extract de la bdd et on envoie les données avec un WS.

les webservice je vais te dire franchement c'est pas moi qui les fait! Tout ce que je peux te dire c'est qu'on utilise .NET et que ca marche plutot bien

Moi si tu veux plus d'info je peux demander à mon collègue qui les réalise? y a pas de problème!

++

Thierry

[Maximil ian]

Si ça le dérange pas, je veux bien quelques infos concernant l'interfaçage des formulaires InfoPath avec des Web Services, surtout au niveau du style généré par le service (document/literal...)

Au passage merci pour la réponse sur les mailing-lists msdn ("virgul" je suppose que c'est toi... le monde est petit )

@+

[virgul]

Salut,

("virgul" je suppose que c'est toi... le monde est petit )

Le monde d'infopath oui effectivement

C'étais le truc sur le WSDL je suppose... (on a été emerdé longtemps avec ca.... ) ce quand tu essaye c'est de renvoyer le xml rempli sur ton webservice? mon english n'est pas très bon sorry


Alors je suis désolé pour celle-ci qui ne va pas beaucoup t'aider:

Nous on utilise VS.Net.

Et le fait est qu'il ne comprend pas ce que tu lui dit alors si tu veux être un peu plus précis ou j'en sais rien quoi de plus (moi j'y connait pas grand chose a tout ca) ! Pour qu'il comprenne de quoi tu parles et qu'il puisse éventuellement te répondre

Bonne Chance!!!

[Maximil ian]

C'étais le truc sur le WSDL je suppose... (on a été emerdé longtemps avec ca.... ) ce quand tu essaye c'est de renvoyer le xml rempli sur ton webservice? mon english n'est pas très bon sorry

C'est ça, maintenant j'ai une erreur "InfoPath ne peut pas utiliser la méthode du service Web sélectionné pour envoyer les données car cette méthode n'accepte pas de données XML valides".

Et le fait est qu'il ne comprend pas ce que tu lui dit alors si tu veux être un peu plus précis ou j'en sais rien quoi de plus (moi j'y connait pas grand chose a tout ca) ! Pour qu'il comprenne de quoi tu parles et qu'il puisse éventuellement te répondre

OK, vu que c'est un web service en .NET il ne doit pas avoir les mêmes soucis que moi vu que c'est du document/literal par défaut... Tu peux juste lui demander s'il a eu le même genre de messages d'erreur que celui décrit plus haut (méthode n'accepte pas de données valides) ?

[virgul]

Tu peux juste lui demander s'il a eu le même genre de messages d'erreur que celui décrit plus haut (méthode n'accepte pas de données valides) ?

Moi ce que je te conseil c'est de faire un bouton pour envoyer ton infopath et tu rajoute du code derrière avec un appel standard de webservice et tu lui envoie le xml la il rale beaucoup moins!!!

Car ce que tu dit me rappelle un problème d'infopath mais je ne me souviens plus le lequel et la solution proposé je ne m'en souviens plus!!! mais de toute facon c'est mieux de faire comme je te dit comme ca au démarrage il ne fait pas de "test" du webservice et c'est seuleument quand tu l'envoie qu'il regarde si il peux l'envoyer!!!

++

Thierry

[Maximil ian]

Pardonnez-moi de revenir encore sur ce topic mais mon projet a connu des revirements qui font qu'on utilisera certainement aussi Open Office finalement... J'aurais donc grand besoin de l'expérience de Grandfather dans ce domaine

- Les mises en forme autorisées au départ étaient les suivantes :
- jusqu'à 10 niveaux de titre
- Paragraphes
- Paragraphes en texte pré-formaté (avec police non proportionnelle - très pratique pour créer simplement des équations avec fractions)
- Liens hypertexte intra et extra document
- Tableaux
- Listes numérotées et à puces
- termes d'index
Les utilisateurs ont très vite trouvé les mises en forme de base insuffisantes et ont demandé des enrichissements supplémentaires (mise en forme des paragraphes dans les tableaux, couleur des caractères, etc.)

Ma question : comment as-tu mis en place ces différentes possibilités de mise en forme dans OOo ? As-tu développé tes propres templates / filtres ?

J'ai essayé le filtre Docbook par défaut d'OOo 2.0 mais l'utilisateur doit passer par le menu "Insérer=>section" pour créer un nouveau paragraphe, choisir exactement le bon style pour créer un titre, les images ne passent pas... Bref, des méthodes de saisie assez peu intuitives et aux possibilités limitées.

Comment contourner ce problème sans forcément toucher au code d'OOo ? Je suis un peu perdu et je dois dire que le site OpenOffice.org, assez bordélique, n'est pas fait pour m'aider...

[GrandFather]

Ma question : comment as-tu mis en place ces différentes possibilités de mise en forme dans OOo ? As-tu développé tes propres templates / filtres ?

Non, je n'ai pas créé de template ni de styles personnalisés. Les utilisateurs ont une liste des mises en forme autorisées, et doivent s'y conformer. Je n'ai pas créé non plus de filtre XML dans OOo (la terminologie employée par OOo est trompeuse : les filtres XML sont en fait des feuilles de style écrites en XSLT), j'ai externalisé la transformation du format OOo en mon format personnalisé, à cause de contraintes n'ayant rien à voir avec OOo. Mais, si on peut l'employer, la solution du filtre XML est plus intéressante car intégrée à OOo.

J'ai essayé le filtre Docbook par défaut d'OOo 2.0 mais l'utilisateur doit passer par le menu "Insérer=>section" pour créer un nouveau paragraphe, choisir exactement le bon style pour créer un titre, les images ne passent pas... Bref, des méthodes de saisie assez peu intuitives et aux possibilités limitées.

Je suis tout à fait d'accord avec toi, c'est bien pour cela que j'ai préféré ne pas imposer de cadre rigide aux utilisateurs (hormis certaines interdictions), et me débrouiller pour que le rendu soit le plus fidèle possible. La contrepartie, c'est que plus c'est facile pour tes rédacteurs, plus tu en baves pour la transformation...

Comment contourner ce problème sans forcément toucher au code d'OOo ? Je suis un peu perdu et je dois dire que le site OpenOffice.org, assez bordélique, n'est pas fait pour m'aider...

Pas besoin de toucher au code de OOo, mais il y a 3 domaines où il faut s'investir beaucoup :
- la programmation XSLT
- La connaissance du format XML des fichiers OOo
- La programmation des extensions pour processeur XSLT, pour gérer ce que XSLT ne saura pas faire ou mal (traitement des images et des tableaux complexes, par exemple)

Sur ces 3 domaines, je peux (et d'autres membres, sans doute) t'apporter toute l'aide que tu souhaites.

[Maximil ian]

OK, donc si j'ai bien compris tu laisses tes utilisateurs mettre en forme le document à leur guise, l'enregistrer (à quel format ? OpenDocument ? SXW ?) et ensuite tu t'arranges pour faire rentrer ça ton moule...

Mais, si on peut l'employer, la solution du filtre XML est plus intéressante car intégrée à OOo.

Effectivement. J'ai (enfin) trouvé un document intéressant sur le sujet : http://books.evc-cit.info/odbook/ch09.html

[GrandFather]

OK, donc si j'ai bien compris tu laisses tes utilisateurs mettre en forme le document à leur guise, l'enregistrer (à quel format ? OpenDocument ? SXW ?) et ensuite tu t'arranges pour faire rentrer ça ton moule...

C'est cela. Le format d'enregistrement est SXW (ça a été développé autour de la version 1.1.1 de OOo), mais je suis en train d'étudier le passage à OOo 2.0 et OpenDocument. Personnellement, je te conseille d'étudier prioritairement OpenDocument ; comme il s'agit d'un standard OASIS, il est vraisemblable que beaucoup d'outils seront développés autour et l'interopérabilité avec Microsoft Office devrait être excellente.

[GrandFather]

Un bon débroussaillage de OpenDocument : http://en.wikipedia.org/wiki/OpenDocument

[Maximil ian]

Un bon débroussaillage de OpenDocument : http://en.wikipedia.org/wiki/OpenDocument

Merci, c'est vrai que c'est bien utile

Au passage, petite question, comment gères-tu la saisie des méta données de tes documents ?
Mes utilisateurs devront leur associer des mots-clés, un nom d'auteur et autres, et j'hésite à passer par un template OOo pour cette saisie. En effet si je mets par exemple une zone Auteur : dans mon template rien ne les empêche de l'effacer (par mégarde ou sciemment) et ma méta-donnée passe à la trappe
J'imagine que le nom de l'auteur peut se récupérer automatiquement à partir du nom de user enregistré dans OOo mais le problème se pose pour d'autres méta-données...

[GrandFather]

L'accès aux méta-données du document se fait par le menu Fichier > Propriétés.

Là, tes utilisateurs pourront enregistrer noms, mot-clés, thème, etc. et ces données seront conservées dans le document. Il n'y a qu'un problème que je ne sais pas résoudre : par souci de confidentialité, l'utilisateur peut choisir de ne pas enregistrer son identité dans le document (il lui suffit de décocher la case "Utiliser les données d'identité" dans l'onglet général), et il n'y a pas moyen de l'en empêcher...