Lorsqu'on produit un document odt à partir d'un template, il est intéressant de pouvoir le compléter tout en gardant le couplage avec les attributs Dynacase-platform.

Ainsi, on pourrait rédiger du texte autour des parties variables qui, elles, seraient mises à jour lors des modifications dans Dynacase-platform.

Il y a 2 usages visibles de ce fonctionnement :

1. la modification du texte autour des données issues de Dynacase-platform que l'on souhaite réimporter
2. la modification des données issues de Dynacase-platform dans le document et que l'on souhaite réimporter

Il faudra distinguer 2 types d'éléments :

• les éléments à afficher inline.
• les éléments à afficher en bloc.

Les éléments inline (atomiques) doivent pouvoir être présentés au sein de paragraphes éditables.

Il s'agit de valeurs simples qui sont présentées au sein de “champ de saisie” ou “liste de saisie” selon ce qu'aura utilisé le créateur du template. Les champs ont un fond grisé qui n'apparaît pas à l'impression mais cela permet de les mettre en en évidence.

Dans le cas du champ de saisie, il est modifiable ce qui peut induire l'utilisateur du document en erreur, donc il est préférable dans ce cas de modification du texte en dehors des données Dynacase-platform, d'utiliser une liste de saisie : elle n'aura qu'une seule valeur ce qui créera l'effet de “readonly” souhaité.

Il sont représentés par des “Section” au sens OpenOffice des sections : il s'agit de paragraphes complets au sein desquels une mise en forme automatisée a pu être générée.

Tous les traitements qui sont à refaire lors d'une possible génération ultérieure doivent être mis au sein des Sections : [IF], [BLOCK], tableaux, listes à puces.

Ces sections seront identifiable par un préfixe “tpl” dans leur nom. Grâce à ce préfixe, à la génération par Dynacase-platform, on génère une nouvelle section non masquée qui contient le résultat. A la deuxième génération, on supprime la section générée précédemment et on la regénère à partir du modèle qui est caché.

Une valeur dans l'ODT template qui serait affichée en dehors d'un champ (de saisie ou liste) ne pourra pas remonter : une fois généré, elle est fusionnée au texte et rien ne permet de la récupérer au sein du document.

Il est donc impératif d'utiliser des champs de saisie pour les valeur en lecture/écriture et des listes de saisie pour les champs en lecture seule.

A noter qu'il est également impératif d'avoir une unicité de présence du champ de saisie dans le document, car si la même valeur est modifiée plusieurs fois, rien ne nous permettra de juger quelle est la bonne valeur à remonter dans Dynacase-platform et un import inconsistant risque d'être effectué.

Les [IF] et [BLOCK] qui contiendrait des champs de saisie ne pourront pas voir leur données remonter : leur fonctionnement n'est pas réversible, leur principe est de générer un affichage, savoir avec certitude comment exploiter une donnée de ces structures est impossible. Par contre il faudra bien les mettre dans des sections adéquates avec “tpl” en prefix dans leur nom car sinon, ces instructions ne seront pas regénérées.

Pour les tableaux et listes, les données pourront remonter, seulement si ils sont bien au sein de sections spéciales. Car sinon, ils ne pourront être regénérés proprement.

Cela ne s'applique pas aux tableaux qui ne seraient pas des listes de données mais juste un tableau de mise en forme avec des champs indépendants (cf. éléments inline).

Les valeurs saisies dans les champs doivent respecter le type de donnée : nombre, texte, date etc … si le format ne correspond pas, la donnée ne pourra pas remonter.

Il doit être possible à tout moment de décider qu'une valeur, atomique ou non, ne sera plus mise à jour par Dynacase-platform. Cela sera géré non pas dans le template mais via un attribut dans Dynacase-platform.

Seul l'attribut Dynacase-platform permettra de savoir que la donnée ne doit pas redescendre.

Il doit être possible à tout moment de décider qu'une valeur, atomique ou non, ne sera plus mise à jour par Dynacase-platform. Cela sera géré non pas dans le template mais via un attribut dans Dynacase-platform.

On pourra sinon utiliser une liste de saisie plutôt qu'un champ de saisie dans le template pour rendre la donnée “readonly” et donc qu'elle ne remonte plus. Mais ca peut être gênant car si la personne remplace la liste de saisie par un champ de saisie, la donnée remontera.

Il doit être facile de copier coller un paragraphe contenant des valeurs couplées à Dynacase-platform.

Quelques macros ajoutées par Dynacase-platform au document peuvent être imaginées pour permettre de gérer simplement les différents éléments couplés à des attributs Dynacase-platform. Par exemple, découpler un champ, supprimer un champ, savoir à quel attribut est lié un champ, savoir de quand date la dernière mise à jour…