Les formulaires manipulent des données. Celles-ci sont stockées dans des conteneurs appelés DataStore.
Il en existe plusieurs types, qui se distinguent par la provenance des données qu’ils contiennent, mais aussi par leur durée de vie.

Les datastore

Nativement, trois DataStore sont manipulés par l’application formulaire au cours du remplissage :

• Le DataStore Utilisateur (« UserData ») : Contient les données injectées à l’ouverture du formulaire par FormServices. Ce DataStore est composé des métadonnées de FormServices (données utilisateur, rôles, groupes, métadonnées, pré-remplissage). Ces informations ne peuvent pas être modifiées par le formulaire.

• Le DataStore Externe (« ExternalData ») : Contient les données alimentées par WebService et DataRequest (StoreOutputInDataStore=false). Ces données sont accessibles pendant la saisie et jusqu’à la production du PDF.

• Le DataStore Brouillon (« DraftData ») : Contient les données alimentées par le formulaire ainsi que par WebService et DataRequest (StoreOutputInDataStore=true). C’est ce DataStore qui est récupéré lors de la sauvegarde d’un dossier. Il est impossible d’y pousser des données commençant par « jsys ».

Le cumul (pool)

À chaque rechargement, le pool de données (c’est-à-dire les données manipulées par le formulaire) est recalculé. Lors de ce calcul, le moteur de FormPublisher cumule les DataStore dans l’ordre suivant :

1. Draft

2. User

3. ExternalData

À la suite de ce cumul, les données nécessaires au fonctionnement du produit (navigation, état des champs), ainsi que toutes les variables temporaires, sont ajoutées (Variable[Submit=false] et Processing variable).

La manipulation d’arbres de données présents dans plusieurs DataStore est à éviter, car elle peut entraîner des effets non prévisibles. Il est donc fortement conseillé, lors de l’appel d’un WebService et/ou d’une DataRequest, d’écrire dans des éléments parents distincts.

L’exemple ci-dessous illustre ce comportement.

<-- UserData -->
<demandeur>
  <mail>mon@mail.com</mail>
  <nom>Lefebvre</nom>
  <profession>CDP</profession>
  <dateNaiss>1985-07-09</dateNaiss>
</demandeur>

<-- ExternalData -->
<demandeur>
  <dateNaiss>1989-07-09</dateNaiss>
  <prenom>John</prenom>
</demandeur>

<-- DraftData -->
<demandeur>
  <nom>Re</nom>
  <age>18</age>
</demandeur>

<-- Variable dans le jxml -->
<Variable Expression="'MOA'" Name="demandeur|profession" />

Le résultat ci-dessous montre qu’une partie de l’objet demandeur n’est pas accessible dans le formulaire.

L’objet demandeur, existant dans le DraftData, prend le pas sur les autres, même si un sous-élément existe et est renseigné dans un autre DataStore. Les variables étant poussées a posteriori, profession apparaît alors dans les données accessibles.

Les données persistées

A la sauvegarde

Le contenu intégral du DraftData est conservé.

A la validation

Les données du DraftData sont transférées dans le DataStore strict (celui qui est transmis) si elles remplissent au moins l’une des conditions suivantes :

• Une Box de l’interview est non désactivée (Disable=false) et visible.

• Une variable avec Submit=true est visible.

• Utilisation d’une méthode technique (non conseillée).

Les Méthodes techniques

Afin de pouvoir accéder aux DataStore (et les mettre à jour), plusieurs méthodes ont été ajoutées dans la classe CompiledDocument. Celles-ci sont donc accessibles dans les FormPublisherExtension via :

• updateDS(String dsName, String dataPath, JilObject jObj) : mets à jour le DataStore.

• updateDSAndPool(String dsName, String dataPath, JilObject jObj) : mets à jour DataStore & Pool de données.

Dans ces méthodes, les paramètres sont les suivants :

• dsName : Nom du DataStore (les codes sont fournis dans les DataStore).

• dataPath : Chemin dans lequel pousser la donnée.

• jObj : objet à pousser.

Exemple et ressources

Pour les développeurs avancés, vous trouverez un exemple d'extension avec Manipulation de données ici

⚠️ Attention : Les dysfonctionnements induits par ce type d’extension ne sont pas couverts par la garantie.