Fabrication de formulaires Cahier de recommandations

Transcription

Fabrication de formulaires
Cahier de recommandations
Juillet 2016
v0.01 – 13/09/2006 BVG
▪ « Cookbook »
v1.00 – 21/01/2009 BVG
▪ Réunions du comité des rédacteurs Jpublisher
v5.00 – 29/10/2010 BVG
▪ adaptation à FormPublisher
v6.06 – 07/10/2011 BVG
▪ nouvelle numérotation des recommandations
▪ adaptation pour un lecteur extérieur à eWBS
V6.30 – 31/07/2015 BVG
▪ Qualité de l'XSD
V6.31 – 31/07/2015 BVG
▪ Ordre des paramètres dans publication.properties
V6.32 – 21/08/2015 FMO
▪ Subversion
V6.33 – 04/09/2015 BVG
▪ Fragments XSD
V6.34 – 10/09/2015 FMO
▪ Fréquence et qualité des commits
V6.35 – 04/02/2016 BVG
▪ FOP en mode serveur en FP33
V6.36 – 29/04/2016 FMO
▪ Comment retrouver l'XSD dans un war (FP33)
V6.37 – 11/07/2016 BVG
▪ Logging maximum pour debug
V6.38 – 16/12/2016 IMI
▪ Notes en bas de page
V6.39 – 16/12/2016 IMI
▪ Utilisation des champs memo
Contact eWBS: Bernard VANGEYTE | [email protected] | 081/40 98 78
Table des matières
Recommandation
Recommandation
Recommandation
Recommandation
Recommandation
Recommandation
Recommandation
Recommandation
Recommandation
Recommandation
Recommandation
Recommandation
Recommandation
Recommandation
Recommandation
Recommandation
Recommandation
Recommandation
Recommandation
Recommandation
Recommandation
Recommandation
n°
n°
n°
n°
n°
n°
n°
n°
n°
n°
n°
n°
n°
n°
n°
n°
n°
n°
n°
n°
n°
n°
1.Degrés de liberté du rédacteur............................................7
2.Moteur deux temps..........................................................10
3.Check-list du rédacteur.....................................................12
4.Qualité de l'environnement...............................................14
5.Qualité d'un projet...........................................................17
6.Ressources communes.....................................................23
7.Dépôt des sources et versionning.......................................25
8.Plan de test....................................................................30
9.Déploiement sur serveur...................................................32
10.Règles de nommage des variables....................................36
11.Pré-remplissage.............................................................43
12.Layout..........................................................................54
13.Nouveau projet..............................................................56
14.Rubriques de renseignements..........................................57
15.Ordre des sections.........................................................60
16.Liste des documents à joindre.........................................62
17.Enquête de satisfaction...................................................66
18.Voies de recours et vie privée..........................................67
19.Typographie..................................................................68
20.Dénominations et logos officiels.......................................72
21.Recommandations de lisibilité..........................................74
22.Principes de mise en page...............................................75
Page 1 sur 102
Juillet 2016
Recommandation
Recommandation
Recommandation
Recommandation
Recommandation
Recommandation
Recommandation
Recommandation
Recommandation
Recommandation
Recommandation
Recommandation
Recommandation
n°
n°
n°
n°
n°
n°
n°
n°
n°
n°
n°
n°
n°
23.Tableaux.......................................................................77
24.Formattage des champs..................................................83
25.Libellés des questions.....................................................84
26.Blocage de l'accès direct.................................................85
27.Accès DB en lecture.......................................................87
28.Utilisation des champs mémo..........................................90
29.Recalcul des totaux........................................................92
30.Liste de paires codes libellés............................................93
31.Itérations......................................................................95
32.Ensemble de questions...................................................97
33.Notifications multiples....................................................98
34.Problèmes de session...................................................100
35.Calcul du pdf avec FOP.................................................101
Page 2 sur 102
Juillet 2016
Synthèse
N
1
Titre
Recommandation
Degrés de
liberté du
rédacteur
Le rédacteur doit toujours retranscrire exactement ce qui est demandé (description du
travail dans le « Mandat » ou faite par les experts en lisibilité), mot à mot, sauf
→ si c'est contraire à une recommandation du présent cahier,
→ si c'est une faute d'orthographe,
→ si c'est contraire aux règles de lisibilité ou à la charte graphique.
Toujours récupérer les logs après un plantage du Studio et les déposer à l'endroit ad
hoc.
2
Moteur deux
temps
À la fin de la réalisation du prototype, certains éléments clefs doivent avoir été validés
définitivement par l'administration responsable du formulaire. Celle-ci peut faire cette
validation, par exemple, sur base du pdf produit lors de la publication du prototype.
3
Check-list du
rédacteur
Avant de commencer à travailler sur l'intelligence du formulaire, le rédacteur doit
s'assurer de disposer de tous les éléments nécessaires à sa réalisation.
4
Qualité de
l'environnement
Toujours minimiser l'utilisation de l'APPLI.REF au strict nécessaire. Toujours essayer
d'abord de trouver une solution valable pour tous les formulaires, donc au moyen du
MY.REF.
Ceci permet d'éviter des fourches (« fork ») de développement et de minimiser les
risques d'erreur, les efforts et les coûts lors d'une mise à jour ou d'une migration.
5
Qualité d'un
projet
Tous les autres fichiers de type bureautique qui sont liés au formulaire doivent être
sortis du projet (et du dépôt Subversion). Tous les autres fichiers de type image
doivent figurer dans un répertoire image de l'APPLI.REF. Tous les autres fichiers de
travail doivent être sortis du projet (et du dépôt Subversion).
S'il y a un seul formulaire (et aucune annexe), il doit s'appeler formulaire.jxml et alors
le fichier de branchement.jxml n'existe pas.
S'il y a plusieurs formulaires et/ou annexes, tous les formulaires se nomment
formulaire_*.jxml et toutes les annexes annexe_*.jxml (tout en minuscules,
séparation des mots par « _ »). Alors branchement.jxml doit exister.
Les fichiers dépendants doivent se nomment include_*.jxml (au niveau d'un
<content>) ou miniclude_*.jxml (à l'intérieur d'un <content> ou équivalent). Les
include et les miniclude ne figurent jamais dans le branchement.jxml.
Les autres fichiers de metadonnées sont dans des fichiers nommés x*_*.jxml (xatoms,
xcomon, xfaq, xinstructions, xvalidation)
Les fichiers publication.properties contiennent 2 volets clairement distincts : « eWBS
PARAMETERS » et ensuite, toutes les autres rubriques communes à jway.
Le premier volet eWBS est dans common/publication.properties et contenir les 3
variables easi.form.direct, easi.form.uploadable, easi.form.sign.type
Le second volet Jway est en partie dans common/publication.properties et contient 3
variables jway.reference.MyRef, jway.reference.Images, jway.reference.Includes.
et en partie dans desktop/publication.properties et contient 3 variables
jway.publication.name, jway.publication.version, jway.boot.edoc
Toujours utiliser le MetaField « departmentLogo ».
Toujours utiliser le logo du SPW (et non le logo de la DG) pour les formulaires du SPW.
La catégorie (meta-field category), la nature (subtitle) et le titre (title) obéissent à
quelques règles éditoriales
6
Ressources
communes
Les ressources communes sont à ne JAMAIS modifier. Leur création et mise à jour
suivent un processus indépendant de tout projet de formulaire.
Toujours reprendre (subversion>update) la dernière version en date des @COMMUN
avant de travailler avec FormPublisher, surtout quand on commence un nouveau
Page 3 sur 102
Juillet 2016
N
Titre
Recommandation
formulaire ou quand on fait une nouvelle version du formulaire.
Ne pas particulariser un bloc commun.
Dès qu'on particularise un bloc commun, on s'expose à de grosses difficultés
d'évolution ou de mises à jour. Il faut éviter au maximum cette pratique.
→ Si on ne peut l'éviter, il faut d'abord soumettre à la réflexion des autres rédacteurs la
possibilité de paramétrer le bloc commun pour le rendre plus flexible.
→ Si vraiment aucune solution n'est possible, la particularisation du bloc commun se
fait en copiant le bloc de @COMMUN vers le projet, et en lui adjoignant un suffixe
explicitant la particularité : « include_particulier »
7
Dépôt des
sources et
versionning
Il faut ajouter systématiquement le numéro de version si le commit correspond à un
déploiement d'un war sur l'environnement de test (et à fortiori sur tout autre
environnement). Le format du commentaire doit être comme suit : « ***
vMM.mm.cc *** » + le commentaire après.
Dans le commentaire après, toujours commencer par rappeler la référence de la
demande JIRA correspondante « JIRA-xxx »
Terminer par un commentaire libre si pertinent.
Nomenclature du nom du war : DGXX_FORM_vMM.mm.cc.Lxx.jjj.eID.war
Lorsque la version en cours (trunk dans subversion) est la version en production :
→ soit on incrémente la version majeure (MM = MM+01) et on remet les autres à 01
(mm=01, cc=01),
→ soit on incrémente la version mineure (mm = mm+01) et on remet les autres à 01
(cc=01).
Lorsque la version en cours (trunk dans subversion) n'est pas la version en production
(version de travail), on incrémente la version correction (cc = cc+01).
Il faut TOUJOURS concordance de numéro de version s'il y a concordance de
traduction.
8
Plan de test
Le rédacteur doit appliquer lui-même la chek-list des tests à son propre
développement, ceci permettant de réduire au maximum les erreurs que le testeur
aura à découvrir.
9
Déploiement sur
serveur
Toujours revérifier l'installation des Metrics lors d'une mise à jour de FormPublisher !!!
Règles de
nommage des
variables
1. pas deux fois le même nom de variable !!!
10
2. pas de caractères spéciaux dans le nom de la variable
3. surtout pas de chiffre au début du nom de la variable !!!
4. utilisation correcte des « pipe » (« | ») pour construire un arbre xml
pertinent, en regroupant les variables, en groupes, sous-groupes, etc. (cf.
exemple ci-dessous)
5. ne pas oublier les <Customizer> pour TOUS les include et les gosub
6. toujours nommage en notation « java », c'est-à-dire une minuscule au
début du nom, avec les mots accolés (pas de « _ ») et séparés simplement
par la majuscule du mot suivant
7. toujours nommage avec des mots lisibles par un humain
8. nommage avec des mots en anglais de préférence
11
Pré-remplissage
Utiliser le bloc commun include_preremplissage_profil.jxml.
12
Layout
Il ne faut pas vouloir modifier les aspects graphiques de présentation de façon
ponctuelle sur un projet de formulaire.
→ Toujours laisser faire le layout.
C'est malgré tout très faisable (au moyen de l'APPLI.REF), mais cela engendre
beaucoup de problèmes d'efficacité de développement ou de mise à jour, et surtout, de
cohérence pour l'usager.
Règle d'or
Page 4 sur 102
Juillet 2016
N
Titre
Recommandation
L'usage d'un layout particulier défini dans l'APPLI.REF est à éviter au maximum.
Pour les RadioBox, on utilise <RadioBox OptionsPerLine="1">.
13
Nouveau projet
Utiliser EASI_ZeroVierge dans Subversion qui contient toutes les rubriques possibles.
14
Rubriques de
renseignements
Les rubriques de renseignement obéissent à quelques règles éditoriales.
Pour la personne de contact :
Il faut toujours faire figurer les renseignements suivants lorsqu'on mentionne une
personne de contact :
→ civilité : « M. » ou « Mme » car il est possible que le prénom ne permette pas de
fixer le genre de la personne, ce qui peut mettre mal à l'aise l'usager
→ prénom en minuscules, nom en majuscule pour distinguer les noms qui ressemblent
à des prénoms
→ téléphone, marqué « Tél. : » et le numéro en notation IBPT
On peut y ajouter : un titre, une adresse courriel, le fax, le site web, etc.
15
Ordre des
sections
Objectif de la standardisation de l'ordre des sections
Permettre aux usagers qui utiliseront plusieurs formulaires différents de retrouver
toujours la même trame, le même ordre, la même structure, autant que possible.
Éviter que le rédacteur traite les contenus similaires de façon trop hétéroclite.
Liste des
documents à
joindre
Il FAUT que le <Title> de la section appelante soit « Liste des documents à joindre ».
17
Enquête de
satisfaction
L'enquête de satisfaction doit figurer dans TOUS les formulaires, SAUF exceptions
précisées dans la liste.
18
Voies de recours
et vie privée
Le titre de la section contenant l'appel au gosub doit être « Protection de la vie privée
et voies de recours » (ou « Protection de la vie privée » dans le second cas)
19
Typographie
Objectifs des règles typographiques
16
Recommandation importantissime !!!
Il FAUT que l'Id de la section appelante soit "depotDocuments", au caractère près.
Montrer une image sérieuse de la Wallonie, de respect de la langue utilisée.
Garantir une certaine harmonie et une cohérence dans la présentation pour l'usager.
20
Dénominations
et logos officiels
En accord avec la Direction de la Communication, les dénominations et logos officiels
doivent être utilisés. Jamais les raccourcis DGO1, etc.
21
Lisibilité
Suivre les 10 règles d'or de la lisibilité.
22
Principes de
mise en page
Minimiser la mise en page, laisser faire les feuilles de style au maximum.
23
Tableaux
Il faut garder le plus possible la structure xml du formulaire conforme à la structure
réelle des données.
La mise en évidence de texte se fait exclusivement en gras.
Le développeur de formulaire doit être très attentif en codant une table avec des
conditions sur les cellules <Td>.
Soit on évite absolument de mettre une condition sur toutes les lignes <Tr>
Soit il faut s'assurer que toutes les conditions couvrent l'ensemble des valeurs
possibles pour la variable de test dans la condition IsVisible.
Ne jamais placer de condition sur un <Paragraph> seul dans une cellule.
24
Formattage des
champs
[À ré-écrire]
25
Libellés des
Toujours utiliser un <Label> pour le libellé d'un champ, dans une <Question>.
Page 5 sur 102
Juillet 2016
N
Titre
Recommandation
questions
Ne jamais mettre « : » à la fin du libellé.
26
Blocage de
l'accès direct
Pour éviter que les usagers accèdent directement à un formulaire sans session, on
bloque l'accès en direct.
27
Accès DB en
lecture
[Pour mémoire, obsolète]
28
Utilisation des
champs mémo
D'une manière générale, l'utilisation du champ mémo n'est pas recommandée. Il faut
toujours préférer proposer de joindre un fichier word, permettant de rédiger en texte
riche.
Attention aux libellés trop longs
Si on utilise les champs mémo malgré la première recommandation, toujours essayer
de limiter la taille des champs, et en particulier celle des champs mémo. Utiliser le
compteur de caractère OBLIGATOIREMENT dès lors qu'il y a une limite sur la taille d'un
champ mémo.
29
Recalcul des
totaux
Lorsqu'il y beaucoup de données sur une page, avec un calcul sur ces données, il faut
ajouter un petit bouton pour que l'usager puisse « Cliquer pour recalculer les totaux ».
30
Liste de paires
codes libellés
On utilise cette technique lorsque l'usager doit pouvoir faire une recherche sur base
d'une paire codes-libellés, c'est-à-dire rechercher un libellé sur base d'un code ou
l'inverse, et lorsque cette liste de paires codes-libellés est peu variable dans le temps,
c'est-à-dire pas de modification plus fréquentes que les mises à jour du formulaire
correspondant.
31
Itérations
Utiliser le DataIterator sur l'objet à multiplier.
32
Ensemble de
questions
Ne pas utiliser l'objet <QuestionSet>.
33
Notifications
multiples
Utiliser le code approprié pour la notification courriels multiples.
34
Problèmes de
session
Pages de longueur raisonnable dans les formulaires
Calcul du pdf
avec FOP
Il faut utiliser le mode serveur.
35
Ne pas fabriquer une page avec trop long tableau ou trop de champs mémo.
Le cas échéant, toujours essayer de les subdiviser.
Page 6 sur 102
Juillet 2016
Recommandation n° 1. Degrés de liberté du rédacteur
1.1 CONTEXTE
DE L'OUTIL
FORMPUBLISHER
L'outil FormPublisher Factory est une « moulinette » automatique qui manipule
(« input ») des fichiers .jxml et des fichiers d'environnement (MY.REF) pour produire
(« output ») une application web en langage java (war).
L'outil FormPublisher Studio est un éditeur expert qui aide le rédacteur à éditer
les fichiers .jxml. NB : cette opération pourrait également être faite dans tout autre
éditeur xml que FormPublisher Studio, ou même dans un éditeur texte simple.
Environnement
MY.REF
FormPublisher
Studio
Fichiers
.jxml
FormPublisher
Factory
Code java
.war
L'environnement de référence (MY.REF) est défini dans la recommandation n° 4.
Les fichiers .jxml décrivent les formulaires en particulier.
Avantages de l'outil :
→ réduire au maximum le travail de mise en page ou de développement de code
→ ce qui permet au rédacteur de pouvoir se concentrer sur l'essence-même du
formulaire : le bon ordre des questions et leur libellé le plus lisible
possible.
1.2 FAIRE
LA MÊME CHOSE DE
2
FAÇONS ÉQUIVALENTES
?
Cependant, l'outil permet, dans de nombreux cas, de faire la même chose de plusieurs
façons quasi équivalentes, mais pas totalement équivalentes.
Exemple, pour faire une liste numérotée, il y a deux solutions :
•
soit l'objet <List>
<List MarkerStyle="number">
<ListItem><Paragraph>Premier objet</Paragraph></ListItem>
<ListItem><Paragraph>Second objet</Paragraph></ListItem>
</List>
•
soit un tableau <Table>
<Table>
<ColumnDefinitions>
<ColumnDefinition Width="3%" />
<ColumnDefinition WidthPaper="97%" />
</ColumnDefinitions>
<TableBody>
Page 7 sur 102
Juillet 2016
<Tr>
<Td><Paragraph>1.</Paragraph></Td>
<Td><Paragraph>Premier objet</Paragraph></Td>
</Tr>
<Tr>
<Td><Paragraph>2.</Paragraph></Td>
<Td><Paragraph>Second objet</Paragraph></Td>
</Tr>
</TableBody>
</Table>
Ceci oblige souvent le rédacteur à se poser des questions, voire le pousse à « réinventer la roue ». Les présentes recommandations ont pour but de réduire cet effet.
Objectif des recommandations :
→ réduire le degré de liberté du rédacteur
→ en lui permettant de rédiger toujours les mêmes choses de la même manière
→ de suivre des recettes toutes faites
→ pour gagner du temps de fabrication, de mise à jour et de maintenance
et surtout → pour uniformiser au mieux l'aspect des formulaires.
Pour l'exemple, la recommandation sera d'utiliser toujours l'objet <List> qui est
prévu à cet effet, qui numérote automatiquement et qui fixe automatiquement la
largeur réservée à la numérotation de la liste.
1.3 RÉDACTION D'UN
FORMULAIRE
Recommandation générale concernant la rédaction du formulaire :
Le rédacteur doit toujours retranscrire exactement ce qui est demandé (description
du travail dans le « Mandat » ou faite par les experts en lisibilité), mot à mot, sauf
→ si c'est contraire à une recommandation du présent cahier,
→ si c'est une faute d'orthographe,
→ si c'est contraire aux règles de lisibilité ou à la charte graphique.
1.4 CONCLUSION
L'application stricte des présentes recommandations doit produire des
formulaires wallons harmonisés pour les usagers, en bénéficiant toujours des
dernières améliorations ergonomiques de l'outil, et doit optimiser le
rendement de fabrication de ceux-ci.
Page 8 sur 102
Juillet 2016
1.5 RAPPORT
DES BUGS DE
FORMPUBLISHER STUDIO
Dans un souci d'amélioration continue, il est évidemment important de corriger
l'outillage de ses bugs. Lorsque l'application FormPublisher Studio se plante, il faut
récupérer les logs qui se trouve dans
C:\Documents and Settings\[User]\Local Settings\Temp\FormPublisherStudio.log
et les copier sous le nom suivant :
S:\developpement\jpublisher\00.installJway\Jway bug
report\FP31\AAAAMMJJx_FormPublisherStudio.log
où AAAAMMJJx est la date à l'envers suivi de « x », une lettre en commençant par
« a », puis « b », etc.
Les logs sont envoyés régulièrement à Jway pour corrections.
Recommandation générale concernant l'utilisation de FormPublisher
Studio :
Toujours récupérer les logs après un plantage du Studio et les déposer à l'endroit
ad hoc.
*****
Page 9 sur 102
Juillet 2016
Recommandation n° 2. Moteur deux temps
Le rédacteur utilisant l'outil FormPublisher peut être amené à intervenir à 2 moments
distincts dans le processus de fabrication du formulaire.
2.1 LE
PROTOTYPE
La première chose à fixer dans la réalisation d'un formulaire, c'est une forme
d'ébauche, appelée « prototype » ou « maquette » en interne chez eWBS, qui doit
contenir :
• le titre (<Title>), la nature (<Subtitle>) et la catégorie du formulaire
(<MetaField Name="category">),
• les
rubriques
de
renseignement
(complètes
et
exhaustives),
cf.
recommandation n° 14, page 57,
• la structure du formulaire, c'est-à-dire les sections et les sous-sections, leur
bon ordre et leur titre, cf. recommandation n° 15, page 60,
• les questions et leur libellé exact et définitif,
• les parties de texte d'explication ou de commentaire,
• la liste des documents à joindre, cf. recommandation n° 16, page 62,
• le libellé de la déclaration sur l'honneur éventuelle, avant la signature,
• la référence aux annexes.
Les éléments de cette ébauche peuvent être :
• soit présentés sur une feuille manuscrite, un mail ou un document électronique
(MS Word ou tableur),
• soit développé directement dans l'outil FormPublisher Studio, donc sous format
pdf.
Pour fixer les idées, le premier temps représente, typiquement, 20 % du temps total
d'utilisation de FormPublisher Studio pour la réalisation complète d'un formulaire.
Recommandation :
À la fin de la réalisation du prototype, certains éléments clefs doivent avoir été
validés définitivement par l'administration responsable du formulaire.
Celle-ci peut faire cette validation, par exemple, sur base du pdf produit lors de
la publication du prototype.
2.2 L'INTELLIGENCE
DU FORMULAIRE
Le second temps du rédacteur consiste d'abord à encoder l'ébauche validée
(uniquement si elle n'a pas déjà été réalisée dans l'outil pour la validation du
prototype).
Ensuite, il s'agit de fixer les aspects dynamiques du formulaire, ce qu'on peut appeler
« l'intelligence », c'est-à-dire, entre autres :
• vérifier le versionning,
fixer les paramètres généraux (publication.properties),
Page 10 sur 102
Juillet 2016
•
•
•
•
•
•
•
•
•
•
•
fixer les <Question>, le contrôle, le nommage de la variable, les options, le
format, la taille, etc.
fixer les conditions sur les <Section>, les <Content>, les <Paragraph>, etc.,
fixer les itérations, les sous-itérations,
développer les codes particuliers (code JIL),
développer les éléments de l'environnement qui doivent être particularisés
(APPLI.REF),
fixer la mise en page pdf (sauts de page + présentation des tableaux),
tester l'intelligence,
vérifier les connexions avec le portail (pré-remplissage, upload de documents,
sauvegarde, soumission),
vérifier la production statique et dynamique du pdf,
préparer à la mise en production (dictionnaire, war)
etc.
Pour fixer les idées, le second temps représente, typiquement, 80 % du temps total
d'utilisation de FormPublisher Studio pour la réalisation complète d'un formulaire.
Recommandation :
s'assurer de disposer de tous les éléments nécessaires à sa réalisation et à sa mise
en ligne. La check-list du rédacteur est là pour l'y aider.
La check-list du rédacteur est détaillée dans la Recommandation n° 3, page 12.
*****
Page 11 sur 102
Juillet 2016
Recommandation n° 3. Check-list du rédacteur
Cette recommandation détaille la 2e partie de la Recommandation n° 2, page 10.
s'assurer de disposer de tous les éléments nécessaires à sa réalisation et à sa mise
en ligne. La check-list du rédacteur est là pour l'y aider.
1. La description complète mais très synthétique du processus de constitution
du dossier de demande : qui signe, quand, où renvoyer, pour quand,
combien de formulaires, combien de documents joints, etc.
2. La validation définitive du prototype par l'administration, qu'il soit déjà
dans FormPublisher ou non.
3. L'accord définitif de l'administration sur la charte graphique par défaut, en
montrant par exemple, le prototype en pdf et en html (cf. pour éviter par
exemple que l'administration concernée ne trouve les formulaires « pas assez
sexys » à la fin du projet).
4. La source (MS Word, pdf ou autre) du formulaire original, si elle existe, ainsi
que les annexes et la notice éventuelles.
5. Un exemple de formulaire complètement rempli (avec des données
réelles, anonymisées si besoin), en essayant d'avoir autant d'exemples que de
cas représentatifs différents.
6. Une indication sur la taille de tous les champs textes, sur le format de
tous les champs avec nombre, sur la taille de tous les champs mémo
(soit en terme de 1/4 de page, de 1/2 page, etc., soit en nombre de caractères,
maximum et éventuellement minimum).
7. Une indication sur le nombre d'éléments (maximum et minimum) pour un
tableau ou une liste itérative.
8. Une indication sur le contrôle de chaque champs où un contrôle spécifique
est souhaité.
9. Une indication sur le caractère obligatoire ou optionnel de chaque champs.
10. Une indication sur les éventuelles conditions de visibilité (IsVisible) d'un
champs, et les éventuelles conditions du caractère modifiable (IsReadOnly) d'un
champs.
11. La description (la plus précise possible) de l'intelligence et des
fonctionnalités souhaitées dans le formulaire html (exemples : le calcul de
sommes, la vérification de dates, les liens DB, les appels à des WS, etc.)
12. Les fonctionnalités de base à supprimer éventuellement (formulaire vierge,
accès direct au formulaire, sauvegarde sur portail, pré-remplissage, etc.)
13. Le nombre de pages maximum si impression papier à grande échelle par
exemple.
14. La traduction à faire (en allemand ou autre).
15. La signature eID ou non et la description des implications procédurales et
organisationnelles pour le backoffice.
16. La connexion technique avec le backoffice si pertinent, et l'expression
explicite du besoin de nommage des variables spécifiques pour le BO.
17. La nécessité de récupérer du contenu backoffice dans le formulaire (via
WebService)
18. La confirmation de la mention vie privée et médiateur.
Page 12 sur 102
Juillet 2016
19. La confirmation de la présence de l'enquête de satisfaction.
20. La description des documents de complément :
◦ la page de validation,
◦ la page après validation (portail),
◦ le glossaire,
◦ la faq,
◦ les instructions pour le remplissage,
◦ les instructions après validation,
◦ les instructions après envoi,
◦ les instructions après signature,
◦ le mail de retour à l'usager (portail),
◦ le mail de retour à l'administration (portail),
◦ le compte récepteur pour l'administration (portail).
21. L'accord (négocié) définitif de l'administration sur la durée des tests, que
ceux-ci soient réalisés en interne exclusivement (tests qualité MAM-NSI + tests
avec des données réelles), ou partiellement à l'administration (tests avec des
données réelles uniquement). Auquel cas, il faut également la mention des
personnes qui vont les réaliser et le temps qu'ils vont pouvoir y consacrer.
22. L'accord définitif de l'administration sur la procédure de validation et la
mention de la personne qui validera.
23. L'accord définitif de l'administration à propos des demandes de corrections
éventuelles :
◦ qui doivent être faites sur un support provenant de la publication de la
dernière version FormPublisher en chantier (et non, par exemple, de la
version MS Word originale),
◦ et qui ne peuvent pas être l'expression de besoins non préalablement définis
(« change request »), auquel cas, une renégociation du délai de réalisation
doit pouvoir être attendue.
24. L'accord définitif de l'administration sur la durée de la mise en ligne
incompressible de 1 semaine, nécessaire notamment pour les tests de charges
à la DEX.
25. La date de mise en ligne voulue, en ayant négocié une date pas trop proche
d'un congé ou d'un long week-end (idéalement entre mardi et jeudi). Idem
pour la date éventuelle de fin de mise en ligne voulue, qui est encore plus
délicate, car celle-ci concentre très potentiellement un surplus de connexions
par les usagers.
26. La mention des endroits où apparaissent le lien vers le formulaire (site
formulaires, avec le contenu exacte à afficher pour présenter ce lien, et/ou sites
spécifiques) et du co-marquage éventuel.
*****
Page 13 sur 102
Juillet 2016
Recommandation n° 4. Qualité de l'environnement
4.1 DÉFINITION
L'environnement contient :
•
l'ensemble des trames de formulaire (« templates »),
•
le recueil de segments linguistiques (phrases ou mots dans un fichier i18n)
utilisés par ces trames,
•
les caractéristiques de présentation (layout, c'est-à-dire feuilles de style,
images, etc.)
•
et les codes informatiques de contrôle, c'est-à-dire « la mécanique » ou
« l'intelligence » (xsl, javascript et java, notamment pour les champs du
formulaire).
4.2 PRINCIPE
DE SUR-DÉFINITION
Les fichiers pris en compte lors de la publication obéissent au principe de surdéfinition (« overruling »).
REF
fichiers de l'environnement commun à tous les clients de Jway, interne au
moteur de FormPublisher Factory
MY.REF
fichiers de l'environnement commun à tous les projets de formulaires
eWBS
APPLI.REF fichiers particuliers à un seul projet de formulaires
D'une manière générale, lors d'une publication,
→ FormPublisher Factory prend d'abord le fichier dans APPLI.REF,
→ s'il n'existe pas dans APPLI.REF, il le prend dans MY.REF,
→ s'il n'existe pas ni dans APPLI.REF, ni dans MY.REF, il prend le fichier par
défaut de l'outil dans REF.
4.3 PARAMÈTRES
DE PUBLICATION.PROPERTIES
Il existe une exception au principe de
recommandation n° 4, page 14 : les fichiers
sur-définition
mentionné
dans
la
APPLI.REF/common/publication.properties
APPLI.REF/desktop/publication.properties
Dans ce cas, ils n'écrasent pas les fichiers correspondants du MY.REF, mais ce sont les
paramètres définis dedans qui s'ajoutent ou écrasent à celles définies dans les fichiers
correspondants du MY.REF.
Page 14 sur 102
Juillet 2016
Pour publication.properties, le principe de « sur-définition » s'applique aux
paramètres et pas aux fichiers entiers.
Ces
paramètres
peuvent
également
formPublisherConfig.properties sur le serveur.
être
définis
dans
un
fichier
Il faut distinguer l'utilisation de ces paramètres en conception (publication par le BA
avec FormPublisher) ou au fonctionnement (exécution par l'usager).
Certains
paramètres n'ont d'effet qu'au moment de la conception, d'autres qu'en
fonctionnement.
L'utilisation de formPublisherConfig.properties du serveur de
déploiement pour y placer des propriétés doit être réservée aux propriétés utilisées au
fonctionnement (ex: adresse de webservices,..). Les propriétés utilisées à la
conception (ex: liées à l'affichage, aux thèmes) seront ignorées sur le serveur de
déploiement.
En résumé, voici l'ordre de priorité des propriétés lors de la conception (ou publication
par le BA) :
1. APPLI.REF\desktop\publication.properties
2. APPLI.REF\common\publication.properties
3. MY.REF\desktop\publication.properties
4. MY.REF\common\publication.properties
5. .jway\formPublisherConfig.properties (sur le PC du FormPublisherStudio)
Voici l'ordre de priorité lors du fonctionnement (ou déploiement ou exécution) :
1. APPLI.REF\desktop\publication.properties
2. APPLI.REF\common\publication.properties
3. MY.REF\desktop\publication.properties
4. MY.REF\common\publication.properties
5. .jway\formPublisherConfig.properties (sur le serveur de déploiement)
4.4 GARANTIES
DE DÉVELOPPEMENT POUR EWBS
Pour eWBS, la garantie corrective (bugs) et évolutive (nouvelles versions ou
nouvelles fonctionnalités) s'applique sur le MY.REF propre à eWBS. Celui-ci
est unique.
NB : Le MY.REF est décliné en autant de versions que de langues utilisées, il existe
donc actuellement un MY.REF traduit en allemand.
Toute correction ou évolution de l'outil ne sera donc JAMAIS répercutée
automatiquement, ni garantie, sur l'APPLI.REF. C'est un point important, car il
guide toute l'approche transversale de la fabrication des formulaires
électroniques.
Recommandation :
Page 15 sur 102
Juillet 2016
Toujours minimiser l'utilisation de l'APPLI.REF au strict nécessaire.
Toujours essayer d'abord de trouver une solution valable pour tous les formulaires,
donc au moyen du MY.REF.
Ceci permet d'éviter des fourches (« fork ») de développement et de minimiser les
risques d'erreur, les efforts et les coûts lors d'une mise à jour ou d'une migration.
*****
Page 16 sur 102
Juillet 2016
Recommandation n° 5. Qualité d'un projet
5.1 STRUCTURE
DE FICHIERS
La structure recommandée pour le répertoire d'un projet de formulaires est :
APPLI.REF/common/publication.properties
APPLI.REF/common/*
APPLI.REF/desktop/publication.properties
APPLI.REF/desktop/*
annexe_*.jxml
branchement.jxml
formulaire_*.jxml
index_glossary.jxml
robots.txt
xatoms.jxml
xcommon.jxml
xfaq.jxml
xinstructions_*.jxml
xvalidation_*.jxml
Recommandation :
Tous les autres fichiers de type bureautique qui sont liés au formulaire doivent être
sortis du projet (et du dépôt Subversion).
Tous les autres fichiers de type image doivent figurer dans un répertoire image de
l'APPLI.REF.
Tous les autres fichiers de travail doivent être sortis du projet (et du dépôt
Subversion).
Les fichiers de type bureautique doivent être déposés dans le dépôt des fichiers
http://forms6.wallonie.be/formulaires/,
•
soit via l'url avec le nom du fichier en direct (si très très peu de mises à jour),
•
soit via slot TYPE=OLD si mises à jour possibles (préférable).
Objectifs :
Le problème des fichiers de type bureaucratiques dans le war du formulaire,
c’est qu’en cas de modification du fichier, il faut republier. Il faut découpler le
cycle de vie de ces fichiers du formulaire proprement dit.
Le problème des autres fichiers de travail et des images, c’est rendre le
répertoire principal lisible, sinon on ne s’y retrouve pas.
5.2 NOMMAGE
STRICT DES FICHIERS
Recommandation :
Page 17 sur 102
Juillet 2016
S'il y a un seul formulaire (et aucune annexe), il doit s'appeler formulaire.jxml et
alors le fichier de branchement.jxml n'existe pas.
S'il y a plusieurs formulaires et/ou annexes, tous les formulaires se nomment
formulaire_*.jxml et toutes les annexes annexe_*.jxml (tout en minuscules,
séparation des mots par « _ »). Alors branchement.jxml doit exister.
Les fichiers dépendants doivent se nomment include_*.jxml (au niveau d'un
<content>) ou miniclude_*.jxml (à l'intérieur d'un <content> ou équivalent). Les
include et les miniclude ne figurent jamais dans le branchement.jxml.
Les autres fichiers de metadonnées sont dans des fichiers nommés x*_*.jxml
(xatoms, xcomon, xfaq, xinstructions, xvalidation)
Exceptions :
• index_glossary.jxml ne peut pas changer de nom
• actuellement, les fichiers liés au listDataHandler n'obéissent pas (encore) à ces
recommandations, mais un travail sera fait pour que ce soit le cas.
Objectif du nommage strict des fichiers :
→ Ceci permet de faire plus facilement des recherches (et remplacement)
massives de chaînes de caractères dans plusieurs projets à la fois, avec
des shell scripts ou avec un éditeur texte tel que Notepad++.
→ Ceci permet aussi au projet d'être facilement testé sur le serveur de tests en
relation avec le portail, sur un slot prédéfini sur des DocumentId="formulaire",
par exemple.
→ Ceci permet également aux rédacteurs de voir d'un seul coup d’œil où
sont les formulaires et annexes, puisque le classement alphabétique des
fichiers d'un répertoire les positionne toujours au même endroit visuellement.
5.3
PUBLICATION.PROPERTIES
L'APPLI.REF est donc TOUJOURS présent dans un projet de formulaire, car au
minimum
deux
fichiers
common/publication.properties
et
desktop/publication.properties doivent y être.
Le contenu de ces fichiers publication.properties doit être typiquement rédigé en
anglais. La structure obligatoire suivante, calquée sur la structure des fichiers
publication.properties présents dans le MY.REF et ceux du REF :
APPLI.REF/common/publication.properties :
# ============================================
# eWBS PARAMETERS
# ============================================
# Permit direct access to eform
# values : ENABLED / DISABLED
easi.form.direct=DISABLED
# Permit document upload
# values : ENABLED / DISABLED
easi.form.uploadable=DISABLED
# Indicate slot signature type
# values :
#
NOSIGN => no signature
Page 18 sur 102
Juillet 2016
#
NORMAL => paper only
#
SIGNABLE => paper or eID
#
ESIGNONLY => eID only
easi.form.sign.type=NORMAL
# ============================================
# PUBLICATION
# ============================================
# Common references
jway.reference.MyRef=D:\\data\\jpublisher\\03.publications\\@COMMUN\\Template_f
older
jway.reference.Images=D:\\data\\jpublisher\\03.publications\\@COMMUN\\Images_fo
lder
jway.reference.Includes=D:\\data\\jpublisher\\03.publications\\@COMMUN\\Include
_folder
# ============================================
# VALIDATION
# ============================================
# Environment cleaning
jway.clean.referenceRepository=true
jway.clean.tmp.file.fo=true
jway.clean.tmp.file.pdf=true
jway.xml.validation=false
APPLI.REF/desktop/publication.properties :
# ============================================
# PUBLICATION
# ============================================
# Indicate the starting document of the publication
# values : formulaire.html/branchement.html
jway.boot.edoc=formulaire.html
# Indicate the name of the publication
jway.publication.name=EASI_DEFAULT_v01.01.01.L3.FP22
# Indicate the version of the publication
jway.publication.version=v01.01.01.L3.FP22
# Indicate if the WAR must be secured or not
jway.secure.war=false
# Disable conditions in PDF until form is completed
jway.xsl.param.disableConditionsInPDF=true
Recommandation :
Les fichiers publication.properties contiennent 2 volets clairement distincts :
« eWBS PARAMETERS » et ensuite, toutes les autres rubriques communes à jway.
Le premier volet eWBS est dans common/publication.properties et contenir au
minimum les 3 variables suivantes :
easi.form.direct=ENABLED/DISABLED
easi.form.uploadable=ENABLED/DISABLED
easi.form.sign.type=NOSIGN/NORMAL/SIGNABLE/ESIGNONLY
Le second volet Jway est en partie dans common/publication.properties et contient
au minimum les 3 variables suivantes :
Page 19 sur 102
Juillet 2016
jway.reference.MyRef=D:\\data\\jpublisher\\03.publications\\@COMMUN\\Template
_folder
jway.reference.Images=D:\\data\\jpublisher\\03.publications\\@COMMUN\\Images_
folder
jway.reference.Includes=D:\\data\\jpublisher\\03.publications\\@COMMUN\\Inclu
de_folder
et en partie dans desktop/publication.properties et contient au minimum les 3
variables suivantes :
jway.publication.name=DGOX_NOM_v01.01.01.L3.FP22
jway.publication.version=v01.01.01.L3.FP22
jway.boot.edoc=formulaire.html/branchement.html
5.4 PARAMÈTRES EWBS
•
•
•
easi.form.direct=ENABLED/DISABLED permet/ne permet pas l'accès direct à un
formulaire sans passer par le portail (cf. recommandation n° 26, page 85)
easi.form.uploadable=ENABLED/DISABLED permet/ne permet pas la possibilité
de joindre des documents électroniquement, via les include_annexe (cf.
recommandation n° 16, page 62)
easi.form.sign.type=NOSIGN/NORMAL/SIGNABLE/ESIGNONLY précise le mode
de signature du formulaire
◦ NOSIGN pour un formulaire à ne pas signer
◦ NORMAL pour un formulaire signable sur papier uniquement
◦ SIGNABLE pour un formulaire signable sur papier ou avec l'eID, au choix
◦ ESIGNONLY pour un formulaire signable avec l'eID uniquement
5.5 PARAMÈTRES JWAY
•
•
•
•
DANS PUBLICATION.PROPERTIES
DANS PUBLICATION.PROPERTIES
jway.publication.name=DGOX_NOM_v01.01.01.L3.FP22 donne le nom du war
jway.publication.version=v01.01.01.L3.FP22 donne le numéro de version et doit
être exactement le nom du war tronqué de son suffixe
jway.boot.edoc=formulaire.html/branchement.html donne le DocumentId cible :
◦ soit « formulaire » si 1 seul formulaire dans le projet
◦ soit « branchement » si plusieurs formulaires dans le projet
Les références doivent absolument être présentes dans le publication.properties
du projet, car si elles sont dans le publication.properties des @COMMUN, cela
ne suffit pas :
◦ jway.reference.MyRef=D:\\data\\jpublisher\\03.publications\\@COMMUN\\Te
mplate_folder
◦ jway.reference.Images=D:\\data\\jpublisher\\03.publications\\@COMMUN\\I
mages_folder
◦ jway.reference.Includes=D:\\data\\jpublisher\\03.publications\\@COMMUN\
\Include_folder
5.6 LOGO
DE L'ADMINISTRATION ÉMETTRICE
Le logo est dorénavant appelé par le nom du fichier image
Page 20 sur 102
Juillet 2016
<MetaField Name="departmentLogo">logoXXX.png</MetaField>
dans le formulaire.jxml.
Les images actuellement disponibles sont placées dans MY.REF\images\logo :
logoASE_fr.png
logoEASI.png
logoEurodyssee_fr.png
logoIFAPME.png
logoSPW_fr.png/logoSPW_de.png
logoVide.png
Cette image sert à préciser le logo de l'administration émettrice qui apparaît en haut à
droite du pdf et qui apparaît dans les pages Renseignement en html.
Attention ! Comme convenu avec la Direction de la Communication (réunion du 22
juin 2009), le logo de l'administration sera la logo du Service public de Wallonie dans
le cas de toutes les DG, et non le logo de la DG (cf. recommandation n° 20,
page 72).
Recommandation :
Toujours utiliser le MetaField « departmentLogo ».
Toujours utiliser le logo du SPW (et non le logo de la DG) pour les formulaires du
SPW.
5.7 TITRES
DU FORMULAIRE
Comme spécifié dans la Recommandation n° 2, page 10, le prototype est l'étape de
fabrication dans laquelle on doit avoir fixé définitivement 3 éléments identitaires du
formulaire importants :
• La catégorie (<MetaField Name="category">) est un libellé placé dans le
header du formulaire électronique et dans le header de la première page du
formulaire papier. Ce libellé doit permettre de regrouper (de façon très lisible
et compréhensible) plusieurs formulaires ayant un point commun (dispositif
commun, service administratif commun, démarche commune, événement
déclencheur commun, ou autre).
• La nature du formulaire (<Subtitle>) doit permettre (par un vocabulaire
cohérent entre tous les formulaires wallons) à l'usager de comprendre
rapidement ce que le formulaire va lui apporter. La nature du formulaire doit,
sauf rares exceptions, être choisi dans une liste exhaustive de possibilités :
◦ Déclaration
◦ Demande de prime
◦ Demande de subside
◦ Demande d'enregistrement
◦ Demande d'agrément
◦ Inscription
◦ Rapport d'activité
• Le titre (<Title>) doit donner l'identité du formulaire, sans reprendre ni le mot
« formulaire », ni les mots repris dans la nature, ni les mots repris dans la
catégorie.
Page 21 sur 102
Juillet 2016
Recommandation :
La catégorie (meta-field category), la nature (subtitle) et le titre (title) obéissent à
quelques règles éditoriales
5.8 NETTOYAGE
•
Toujours nettoyer le répertoire d'un projet de tous fichiers inutiles (sources
« word », fichiers .jxml non utilisés, fichiers doublons ou de backup *.~jxml,
etc.).
•
Toujours revalider l'APPLI.REF et ne garder que les différences qu'il faut
réellement garder pour le formulaire.
Objectifs du nettoyage :
Garder un environnement le plus générique possible, pour minimiser le travail sur
les mises à jour, et surtout éviter de « forker ».
Éviter de déposer des fichiers inutiles dans le dépôt de sources subversion.
*****
Page 22 sur 102
Juillet 2016
Recommandation n° 6. Ressources communes
6.1 DESCRIPTION
Les ressources communes à tous les formulaires eWBS sont :
@COMMUN\Images_folder
banque d'images
@COMMUN\Include_folder
blocs
communs :
gosub_XXXX.jxml
include_XXXX.jxml + miniclude_XXXX.jxml
@COMMUN\Template_folder
environnement MY.REF
robot.txt
fichier obligatoirement présent dans le répertoire de tout
projet / nécessaire pour éviter aux robots internet de
scanner les formulaires
Mode d'emploi
ensemble de fichiers communs à tous les formulaire,
déposés sur le portail
+
Recommandation :
Les ressources communes sont à ne JAMAIS modifier. Leur création et mise à
jour suivent un processus indépendant de tout projet de formulaire.
6.2 DÉPÔT
DE SOURCES
Les ressources communes (@COMMUN) sont déposées dans subversion.
Le répertoire @COMMUN doit être placé dans le même répertoire que les répertoires
projet des formulaires, soit dans D:\data\jpublisher\03.publications\@COMMUN
Recommandation
Toujours reprendre (subversion>update) la dernière version en date des
@COMMUN avant de travailler avec FormPublisher, surtout quand on commence
un nouveau formulaire ou quand on fait une nouvelle version du formulaire.
6.3 BLOCS
COMMUNS
Règle d'or
Ne pas modifier un bloc commun, puisque c'est une ressource commune.
Les blocs communs sont utilisés dans de nombreux projets de formulaire, et
l'impact d'une modification peut être grand. Les blocs communs peuvent évoluer,
mais cette évolution relève d'une réflexion commune à tous les rédacteurs de
formulaire et transversale à tous les projets de formulaire.
Page 23 sur 102
Juillet 2016
Recommandation
Ne pas particulariser un bloc commun.
Dès qu'on particularise un bloc commun, on s'expose à de grosses difficultés
d'évolution ou de mises à jour. Il faut éviter au maximum cette pratique.
→ Si on ne peut l'éviter, il faut d'abord soumettre à la réflexion des autres
rédacteurs la possibilité de paramétrer le bloc commun pour le rendre
plus flexible.
→ Si vraiment aucune solution n'est possible, la particularisation du bloc
commun se fait en copiant le bloc de @COMMUN vers le projet, et en lui
adjoignant un suffixe explicitant la particularité : « include_particulier »
*****
Page 24 sur 102
Juillet 2016
Recommandation n° 7. Dépôt des sources et versionning
7.1 DÉPÔT
DES SOURCES
SVN
eWBS utilise Subversion (« SVN ») pour conserver et partager tous les fichiers liés à
la conception des formulaires. Subversion est un serveur, accessible via internet, qui
permet la mise en commun de fichiers, en vue d'un travail collaboratif tel que le
développement informatique, en permettant de partager et de synchroniser les
dossiers de travail de plusieurs développeurs.
Le serveur SVN de eWBS est accessible via l'url http://svn.easi.wallonie.be et est
soumis à un accès autorisé.
eWBS utilise Subversion associé à Tortoise (http://tortoisesvn.net/downloads pour
son téléchargement et son installation par un administrateur du PC). Tortoise, une
fois correctement installé, ajoute des fonctionnalités nouvelles (options) au « clic
droit » sur un fichier ou un dossier dans l'explorer de Windows (cf. screenshot cicontre).
Voici la description des principales options :
7.1.1 Checkout
Le dépôt est le dossier commun sur le serveur et la copie de travail est le dossier
sur le PC du développeur.
SVN Checkout permet de créer une copie de travail à partir du dépôt. Il est alors
nécessaire de préciser l'url du dépôt (url repository) et l'url de la copie de travail sur
son PC (checkout directory).
Pour un projet de formulaires dont le nom est
DGXX_FORM (cf. section 7.2 pour la définition de la nomenclature à suivre), l'url
repository sera : http://svn.easi.wallonie.be/DGXX_FORM /trunk/fr
7.1.2 Copie de travail
Une fois déposés sur son PC, tous les fichiers ont un statut « vert » (marque « v »
dans un cercle vert devant le fichier). Dès qu'un fichier est modifié sur le PC par le
développeur, il passe au statut « rouge » (marque « ! » dans un cercle rouge devant
le fichier), ce qui signifie qu'il devient différent du dépôt et qu'il est désynchronisé.
Pour qu'il soit transmis, partagé et utilisable par les autres développeurs, il faudra
d'abord à nouveau le resynchroniser (cf. commit section 7.1.3 ci-dessous).
7.1.3 Update et Commit
Les options Tortoise sont disponible via un clic droit sur n'importe quel fichier ou
dossier de la copie de travail. Les plus importantes et utiles sont « update » et
« commit ».
Commit permet de mettre à jour le dépôt avec les éléments (fichiers ou dossiers)
désynchronisés (marqués en rouge) de la copie de travail.
C'est en quelque sorte « l'upload » du travail du développeur.
Update permet de de mettre à jour la copie de travail avec les éléments qui ont été
modifiés et commités par d'autres depuis la dernière synchronisation.
Page 25 sur 102
Juillet 2016
C'est en quelque sorte le « download » du travail des autres développeurs.
Il est vivement conseillé de mettre à jour la copie de travail (update) avant toute
modification et de transmettre le travail réalisé (commit) après chaque étape
importante de développement.
Bonne pratique
Limiter les commits : pas besoin de commiter à chaque modification d’un fichier,
regrouper de manière cohérente les commits.
Lors d'un commit, il est très important de bien commenter le travail réalisé, car cette
information sera utile plus tard et sera utilisée par tous les autres développeurs pour
s'informer rapidement de la teneur du travail réalisé. Un numéro de version peut être
ajouté pour mieux faire le lien entre la release dans SVN et le nom du war publié.
Recommandation
Il faut ajouter systématiquement le numéro de version si le commit correspond à
un déploiement d'un war sur l'environnement de test (et à fortiori sur tout autre
environnement). Le format du commentaire doit être comme suit : « ***
vMM.mm.cc *** » + le commentaire après.
Dans le commentaire après, toujours commencer par rappeler la référence de la
demande JIRA correspondante « JIRA-xxx »
Terminer par un commentaire libre si pertinent.
Objectif de la recommandation :
Il faut toujours pouvoir retrouver la release exacte dans SVN qui correspond
exactement au war déposé quelque part. Et toujours pouvoir raccrocher la release à
la tâche JIRA.
NB : Les règles de nomenclatures pour le numéro de version sont expliquées aux
sections 7.2 et 7.3 infra.
7.1.4 Show log
Show log permet d'afficher le résumé des dernières actions effectuées sur le dépôt :
qui a fait quoi, et quand. C'est très utile pour visualiser les modifications apportées.
7.1.5 Clean up
Parfois, les marqueurs rouges et verts ne reflètent pas le statut réel d'un fichier après
de multiples update et commit.
Il se peut également qu'un marqueur jaune
apparaisse, signalant un réel problème de conflit de statut entre le dépôt et la copie
de travail. Clean up permet de tenter (et souvent, il y arrive) de nettoyer les
marqueurs.
Page 26 sur 102
Juillet 2016
7.1.6 Autres options
En dehors des options décrites ci-dessus, il existe de nombreuses options dont la
description est moins utile pour une utilisation basique.
7.2 NOMENCLATURE
À SUIVRE
Nomenclature du nom DGXX_FORM → pour les formulaires SPW
d'un projet
OIP_FORM → pour les formulaires des OIP
exemples :
DGO5_InfraPersAgees, FOREM_AccompagnementChomeurs
/!\ Il faut que ce nom de projet soit EXACTEMENT celui
du projet dans le dépôt de sources SVN.
Nom du war
correspondant, pour
la mise en chantier
DGXX_FORM_vMM.mm.cc.Lxx.jjj.eID.war
exemple :
DGO5_InfraPersAgees_v01.04.06.L3.FP2.eID.war
DGXX_FORM_vMM.mm.cc.war
Nom du war
correspondant pour la exemple :
mise en production
DGO5_InfraPersAgees_v01.04.06.war
Où
DGXX = DGT, DGO1, DGO2, DGO3, DGO4, DGO5, DGO6, DGO7
OIP = ASE, IFAPME, FOREM, etc.
FORM est le nom du formulaire (règle de nommage : nom composé, pas séparé
par des « _ », mais séparé par la majuscule du mot suivant)
Version = vMM.mm.cc
MM = version majeure
mm = version mineure
cc = version corrective
Information
après la
version :
Lxx.jjj.eID
7.3 INCRÉMENT
Lxx = version du layout (L1, L2A, L3, etc.)
jjj = version de l'outil (II.2.1, II.3.1, II.4, FP1, FP2, etc.)
eID = si signature eID
DE VERSION
Recommandation
Lorsque la version en cours (trunk dans subversion) est la version en production :
Page 27 sur 102
Juillet 2016
→ soit on incrémente la version majeure (MM = MM+01) et on remet les
autres à 01 (mm=01, cc=01),
→ soit on incrémente la version mineure (mm = mm+01) et on remet les
autres à 01 (cc=01).
Lorsque la version en cours (trunk dans subversion) n'est pas la version en
production (version de travail), on incrémente la version correction (cc =
cc+01).
7.4 VERSION
MINEURE OU MAJEURE
?
L'incrément de version mineure est le plus courant. L'incrément de version majeure
n'intervient que lorsque :
•
soit le formulaire est revu fondamentalement,
•
soit le formulaire subit une mise à jour correspondant à un changement annuel
(ou trimestriel ou autre, cf. « runs » pour Prime à l'emploi),
•
soit à fortiori lorsque cette nouvelle version doit cohabiter avec la
précédente (exemple : les primes énergie),
•
soit une combinaison de plusieurs de ces raisons.
7.5 PROCÉDURE
POUR INCRÉMENT DE VERSION
1. Vérifier si la version en cours (dans le trunk de subversion) est une version en
chantier ou une version en production.
2. Incrémenter le numéro de version tel qu'expliqué à la section 7.3 ci-dessus et
modifier les éléments suivants :
◦ APPLI.REF/publication.properties/jway.publication.name=DGXX_FORM_v
MM.mm.cc.Lxx.jjj.eID
◦ APPLI.REF/publication.properties/jway.publication.version=vMM.mm.cc.L
xx.jjj.eID
◦ commit dans subversion avec le commentaire obligatoire suivant :
« *** vMM.mm.cc *** », cf. section 7.1.3.
7.6 CONCORDANCE
DES VERSIONS LINGUISTIQUES
Recommandation
Il faut TOUJOURS concordance de numéro de version s'il y a concordance de
traduction.
Ce qui signifie par exemple que lorsqu'un formulaire existe en version FR et DE, lors
de sa mise à jour :
•
si modification FR uniquement (c'est-à-dire qu'on n'a pas le temps de modifier
immédiatement la version DE), alors on incrémente la version FR uniquement,
Page 28 sur 102
Juillet 2016
•
ensuite, après mise à jour de la version DE, on incrémente les 2 versions FR et
DE, même si la version FR n'a pas subi de modification ; il est d'ailleurs très
très rare que la version FR ne soit pas modifiée lors de la traduction en DE...
Il existe donc souvent de 2 étapes de versionning lors de l'existence d'une traduction :
Étape
Version FR
Version DE
initiale
vMM.mm.cc
vMM.mm.cc
1: màj FR
cc=cc+1
cc (car inchangé)
2: màj DE
cc=cc+2
cc=cc+2
*****
Page 29 sur 102
Juillet 2016
Recommandation n° 8. Plan de test
8.1 CONTENU
DES TESTS
Les tests eWBS sont décomposés en 8 axes :
1) PDF frontpage
2) Structure xml du formulaire
3) PDF typographie
4) PDF corps
5) WEB
6) WEB relation avec le portail
7) Structure xml du datastore (avec analyse du tableau produit par 1 xslt)
8) Tests spécifiques au formulaire
Chaque axe est décomposé en une liste de points à vérifier de façon exhaustive et
commentée. Cf. document de plan de test.
Le dépôt du war de test doit se faire sur forms6.test.wallonie.be, et le lien doit être
fait avec l'un des slots de test mentionnés à la recommandation n° 9, page 32.
Recommandation :
Le rédacteur doit appliquer lui-même la chek-list des tests à son propre
développement, ceci permettant de réduire au maximum les erreurs que le testeur
aura à découvrir.
8.2 ARCHIVAGE
DES TESTS
Les résultats des tests font l'objet par l'analyste de la rédaction d'une tâche JIRA à
laquelle on attache le plan de tests.
Pour stockage consolidé, on peut ranger les résultats des tests avec les anciens sur S:
dans le répertoire
S:\developpement\jpublisher\06.planTests\DGXX_FORM\TESTS_yyyymmdd_TRI\*.odt
Les datastores utilisés sont rangés sur S: dans le répertoire
S:\developpement\jpublisher\06.planTests\DGXX_FORM\DS_yyyymmdd\*.ds
Où
DGXX_FORM est le nom du projet
yyyymmdd est la date à l'envers
TRI est le trigramme du testeur
Page 30 sur 102
Juillet 2016
8.3 DEBUGGING
Pour tracer les appels webservice de manière très précise, et volumineuse, il est
possible de modifier le fichier logging.properties inclus dans jilpages.jar dans WEBINF/lib du war produit par l'opération de packaging.
Cette modification peut être faite avec un utilitaire comme 7zip avant le déploiement
du war.
La modification revient à ajouter en fin de fichier
httpclient.wire.header.level=FINE
et modifier la ligne :
java.util.logging.FileHandler.level= INFO
par la ligne :
java.util.logging.FileHandler.level= ALL
De la sorte les header produit lors de l'appel du webservice apparaîtront dans le fichier
de log.
Il est possible d'ajouter également en fin de fichier :
httpclient.wire.content.level=FINE
De la sorte le contenu de l'échange apparaîtra également.
Attention ! Les logs ainsi générés sont très volumineux mais également très
explicites. Ils peuvent donc convenir pour des tests mais leur usage doit être très
limité.
*****
Page 31 sur 102
Juillet 2016
Recommandation n° 9. Déploiement sur serveur
9.1 LISTE
Serveur
DES SERVEURS
Webserveur DNS
Remarque : accessibilité eWBS
production Tomcat 6
forms6.wallonie.be
validation
Tomcat 6
forms6.valid.wallonie.be non accessible en direct
test
Tomcat 6
forms6.test.wallonie.be
9.2 PROCÉDURE
Cette
•
•
•
accessible en lecture uniquement
accessible à eWBS
DE MISE EN TEST ET VALIDATION
procédure concerne les cas suivants :
Test qualité
Validation par l'administration d'une version prototype
Validation finale par l'administration
Procédure :
1. Publier l'environnement sous le nom
DGXX_FORM_version.Lxx.FPx.eID.war
2. Pour tester le pré-remplissage, la sauvegarde, l'adjonction de
documents (upload), les courriels d'accusé d'envoi ou de notification à
l'administration, la signature papier, la signature eID ou la non
signature, la soumission, la nouvelle demande, etc. :
◦ transférer le war sur forms6.test.wallonie.be, via la console Tomcat
ou via un transfert FTP (ou transmettre le war à quelqu'un qui a
accès au serveur forms6.test.wallonie.be)
◦ identifier le slot défini pour chaque formulaire du war --> par
exemple, le 10985
◦ pour le test du formulaire électronique ouvrir le lien
http://espacepersonnel.wallonie.be/download?
FORMULAIRE_ID=10985&LANG_ID=FR&TYPE=PEL
◦ pour le test du formulaire pdf vierge ouvrir le lien
http://espacepersonnel.wallonie.be/download?
FORMULAIRE_ID=10985&LANG_ID=FR&TYPE=PDF
◦ modifier le courriel de destination du courriel de notification (ou
demander à quelqu'un qui a accès à la DB de test) : y placer le
courriel du testeur ou un courriel auquel le testeur aura accès -->
champ FORMULAIRE_EMAIL_DEST de la table FORMULAIRE
◦ NB : ce champ surcharge le champ FORMULAIRE_IDUSER_DEST de
la table USERS, donc après le test, il faut vider ce champ
Page 32 sur 102
Juillet 2016
FORMULAIRE_EMAIL_DEST dans la table FORMULAIRE
3. Envoyer un courriel avec les liens
◦ au testeur si test qualité,
◦ à l'analyste spécialisé si envoi en validation ou en test à l'extérieur.
Informer le testeur qu'après clic sur le lien, il devra entrer un login et
un mot de passe valides. Lui suggérer d'utiliser son propre compte de
test.
9.3 PROCÉDURE
DE MISE EN PRODUCTION
Cette procédure concerne uniquement le cas de la mise en production.
Procédure :
1. Publier l'environnement sous le nom DGXX_FORM_version.Lxx.FPx.eID
2. Renommer le nom du fichier .war en : DGXX_FORM_version.war, c'està-dire qu'on supprime Lxx (layout), Jpxx (version de Jpublisher), et
l'éventuel eID
Cette étape est importante :
◦ pour pouvoir distinguer les wars en prod des wars en chantier,
◦ pour le fonctionnement des scripts CGI qui produisent un tableau
des wars sur chaque serveur
3. Déposer le war DGXX_FORM_version.war sur forms6.test.wallonie.be dans
/home/sites/forms6/appl/
4. [obligatoire] Enregistrer l'xsd et le déposer dans
S:\xterne\jpublisher\fait\XXX\DICO_aaaammjj\ pour un dépôt ultérieur
et définitif dans S:\developpement\jpublisher\06.tests xsd dicos
datastores\DGXX_FORM\DICO_aaaammjj\
NB : aaaammjj = année – mois - date
5. [facultatif] Enregistrer le dictionnaire *.html et le déposer dans
S:\xterne\jpublisher\fait\XXX\DICO_aaaammjj\ pour un dépôt ultérieur
et définitif dans S:\developpement\jpublisher\06.tests xsd dicos
datastores\DGXX_FORM\DICO_aaaammjj\
6. Encoder la demande de mise en production dans l'outil de la DEX qui
s'appelle BMC, en y ajoutant la demande de modification du slot
(champ FICHIER_URL de la table FICHIER) :
◦ http://helpdesk.intra.spw.wallonie.be, login = ..., pwd = ...
7. Vérifier les contenus des courriels de retour et vérifier le contenu des
Page 33 sur 102
Juillet 2016
fiches descriptives Nostra sur le portail Wallonie.
9.4 PRISE
EN COMPTE DES CARACTÈRES SPÉCIAUX PAR
FOP
La prise en compte des caractères spéciaux (lettres grecques, ou symboles
mathématiques, par exemples) dans le PDF est assurée par l'installation correcte de
FOP à la fois sur la machine de publication (PC) et sur le serveur de formulaires.
Attention ! FormPublisher ne détectera pas une mauvaise prise en compte et la
publication se déroulera normalement. Il faut donc vérifier le résultat sur le pdf.
/!\ Sur le PC (pour la fabrication du pdf vierge) et sur le serveur des
formulaires (pour la fabrication du pdf dynamique).
9.4.1 Sur le PC
Ajouter les lignes suivantes (si elles n'y figurent pas) dans le fichier suivant :
C:\Documents and Settings\user\.jway\fop.xconf
dans la balise <fonts>.
Attention de bien vérifier les chemins (path) par rapport à la machine.
<fonts>
<font metrics-url="C:\Applications\jwayFP22\fop-1.0\MyMetrics\arial.xml"
kerning="yes" embed-url="file:///C:\WINDOWS\Fonts\ARIAL.TTF">
<font-triplet name="Arial" style="normal" weight="normal"/>
</font>
<font metrics-url="C:\Applications\jwayFP22\fop-1.0\MyMetrics\arialBold.xml"
kerning="yes" embed-url="file:///C:\WINDOWS\Fonts\ARIALBD.TTF">
<font-triplet name="Arial" style="normal" weight="bold"/>
</font>
<font metrics-url="C:\Applications\jwayFP22\fop1.0\MyMetrics\arialItalic.xml" kerning="yes" embedurl="file:///C:\WINDOWS\Fonts\ARIALI.TTF">
<font-triplet name="Arial" style="italic" weight="normal"/>
</font>
<font metrics-url="C:\Applications\jwayFP22\fop1.0\MyMetrics\arialBoldItalic.xml" kerning="yes" embedurl="file:///C:\WINDOWS\Fonts\ARIALBI.TTF">
<font-triplet name="Arial" style="italic" weight="bold"/>
</font>
</fonts>
Recommandation :
Toujours revérifier l'installation des Metrics lors d'une mise à jour de
FormPublisher !!!
9.4.2 Sur le serveur de formulaires
Copier les quatre fichiers dans le répertoire « MyMetrics » de l'installation fop :
Page 34 sur 102
Juillet 2016
sur forms.test.wallonie.be :
/opt/fop/mymetrics/arial.xml
/opt/fop/mymetrics/arialBold.xml
/opt/fop/mymetrics/arialBoldItalic.xml
/opt/fop/mymetrics/arialItalic.xml
/opt/fop-1.0/conf/fop.xconf
*****
Page 35 sur 102
Juillet 2016
Recommandation n° 10. Règles de nommage des variables
10.1 PRINCIPES
Une bonne structure du datastore dépend du nommage correct des variables des
champs. Quelques règles sont à suivre obligatoirement, soit pour éviter les bugs,
soit pour obtenir une structure cohérente, et lisible par un humain.
Recommandations :
1. pas deux fois le même nom de variable !!!
2. pas de caractères spéciaux dans le nom de la variable
3. surtout pas de chiffre au début du nom de la variable !!!
4. utilisation correcte des « pipe » (« | ») pour construire un arbre xml
pertinent, en regroupant les variables, en groupes, sous-groupes, etc. (cf.
exemple ci-dessous)
5. ne pas oublier les <Customizer> pour TOUS les include et les gosub
6. toujours nommage en notation « java », c'est-à-dire une minuscule au
début du nom, avec les mots accolés (pas de « _ ») et séparés simplement
par la majuscule du mot suivant
7. toujours nommage avec des mots lisibles par un humain
8. nommage avec des mots en anglais de préférence1
Exemples :
Le nommage des variables successivement comme suit :
Name="demandeur|identification|nom"
Name="demandeur|identification|prenom"
Name="demandeur|adresse|rue"
Name="demandeur|adresse|codePostal"
Name="demandeur|adresse|localite"
Name="demandeur|telecom|tel"
Name="demandeur|telecom|mail"
Name="objetDeLaDemande"
permet d'obtenir un datastore dont l'arbre xml est le suivant :
<datastore>
<demandeur>
<identification>
<nom/>
Attention ! Cette recommandation fait partie des bonnes pratiques générales de la
programmation informatique, mais l'usage du français a été fort répandu dans la
plupart des projets de formulaires (raison historique antérieure à cette
recommandation), notamment dans les blocs communs. Cette recommandation de
nommage en anglais est donc de facto difficile à suivre, sauf pour tout nouveau
formulaire.
1
Page 36 sur 102
Juillet 2016
<prenom/>
</identification>
<adresse>
<rue/>
<codePostal/>
<localite/>
</adresse>
<telecom>
<tel/>
<mail/>
</telecom>
</demandeur>
<objetDeLaDemande/>
</datastore>
10.2 DICTIONNAIRE
Le dictionnaire des variables d'un formulaire est l'ensemble des variables des
champs du formulaire, avec leur type, leur taille, leur format, etc.
Le dictionnaire peut être obtenu au moyen d'une xslt qui permet de produire un
tableau html via, par exemple, les applications XALAN ou XSLTPROC.
Pour XALAN :
1. copier XALAN en
C:\apps\xalan-j_2_7_1
2. ajouter ce répertoire dans le path
3. zParseQuest4.xsl doit bien se trouver dans
S:\developpement\jpublisher\xslt_extract_from_jpublisher
Dans FormPublisher Studio, le dictionnaire est disponible via l'onglet « Data
Dictionary », tout en bas à gauche.
10.3 GRAMMAIRE
XSD
La grammaire des variables d'un formulaire est la description des règles qui
régissent le schéma xml du datastore. Cette grammaire est matérialisée par un
fichier xsd, format xml particulier.
Dans FormPublisher Studio, la grammaire est disponible via l'onglet « Schema » à
côté de « Preview|Edit|Flow|XML ». NB : Si l'onglet n'apparaît pas, il faut aller dans
« Tools > Preferences > General » et cocher « Show Document Schema ».
Depuis FormPublisher 3.3, les schémas XSD sont produits automatiquement et
sauvegardés dans le war.
http://ENV/DGOX_NOM_vxx.xx.xx.L3.FP33/XSDs/documentId.xsd
http://ENV/DGOX_NOM_vxx.xx.xx.L3.FP33/XSDs/signed/documentId.xsd
où ENV est soit forms6.test.wallonie.be, soit forms6.valid.wallonie.be, soit
forms6.wallonie.be
Pour retrouver l'XSD, il faut donc connaître le documentId.
Page 37 sur 102
Juillet 2016
10.4 PROBLÈME XSD
Certains éléments ou attributs d'éléments ne sont pas émis correctement ou
complètement.
10.4.1 pour les RadioBox séparés.
Si on sépare les <Option> d'un <RadioBox>, cela peut produire une XSD où certaines
options manquent.
Exemple :
<Content IsVisible="($(demande|objet)=='etablissementHotelier')">
<Paragraph>
<Question>
<Label>Vous sollicitez une autorisation pour porter la dénomination
suivante</Label>
<RadioBox Name="demande|denomination" IsRequired="true" DataType="string">
<Option Value="hotel">Hôtel</Option>
<Option Value="appartHotel">Appart-hôtel</Option>
<Option Value="hostellerie">Hostellerie</Option>
<Option Value="motel">Motel</Option>
<Option Value="pension">Pension</Option>
<Option Value="relais">Relais</Option>
<Option Value="auberge">Auberge</Option>
</RadioBox>
</Question>
</Paragraph>
</Content>
<Content IsVisible="($(demande|objet)=='camping')">
<Paragraph>
<Question>
suivante</Label>
<Option Value="campingTouristique">Terrain de camping touristique</Option>
<Option Value="campingFerme">Terrain de camping à la ferme</Option>
</RadioBox>
</Question>
</Paragraph>
</Content>
Dans cet exemple, l'xsd produite sera :
<xs:element name="denomination" minOccurs="0">
<xs:complexType>
<xs:simpleContent>
<xs:restriction base="String">
<xs:enumeration value="campingTouristique" />
<xs:enumeration value="campingFerme" />
</xs:restriction>
</xs:simpleContent>
</xs:complexType>
</xs:element>
Pour assurer une liste complète d'options, il faut adopter l'une des trois solutions :
Page 38 sur 102
Juillet 2016
1. Utiliser une liste complète d'options pour chaque instance de la
<Question> et exploiter l'attribut IsVisible sur les <Option> de sorte à
n'afficher que celles demandées à un endroit donné.
2. Utiliser une <Question> avec toutes les <Options> qui seraient
toujours en IsVisible = false en fin de formulaire.
3. Mettre les instances de cette même <Question> dans un seul
<Content> et n'afficher que l'instance qui est acceptable à un moment
donné.
Dans l'exemple, si on peut regrouper les <Paragraph>, la solution 3 convient et donne
le code suivant :
<Content>
<Paragraph IsVisible="($(demande|objet)=='etablissementHotelier')">
<Question>
suivante</Label>
</RadioBox>
</Question>
</Paragraph>
<Paragraph IsVisible="($(demande|objet)=='camping')">
<Question>
suivante</Label>
<Option Value="campingTouristique">Terrain de camping touristique</Option>
</RadioBox>
</Question>
</Paragraph>
</Content>
Dans ce cas, l'XSD sera :
<xs:element name="denomination" minOccurs="0">
<xs:complexType>
<xs:simpleContent>
<xs:restriction base="String">
<xs:enumeration value="hotel" />
<xs:enumeration value="appartHotel" />
<xs:enumeration value="hostellerie" />
<xs:enumeration value="motel" />
<xs:enumeration value="pension" />
<xs:enumeration value="relais" />
<xs:enumeration value="auberge" />
<xs:enumeration value="campingTouristique" />
<xs:enumeration value="campingFerme" />
</xs:restriction>
</xs:simpleContent>
</xs:complexType>
Page 39 sur 102
Juillet 2016
</xs:element>
Par contre, la solution 2 est nécessaire si on ne peut pas regrouper facilement les
<Paragraph>, par exemple, lorsque les <Question> sont dans une <Table>. Alors, le
code suivant s'impose :
<Content IsVisible="($(demande|objet)=='etablissementHotelier')">
<Paragraph >
<Question>
suivante</Label>
<RadioBox Name="demande|denomination" DataType="string">
</RadioBox>
</Question>
</Paragraph>
</Content>
<Content IsVisible="($(demande|objet)=='camping')">
<Paragraph >
<Question>
suivante</Label>
<Option Value="campingTouristique">Terrain de camping
touristique</Option>
</RadioBox>
</Question>
<Question IsVisible="false">
<Option Value="campingTouristique">Terrain de camping
touristique</Option>
</RadioBox>
</Question>
</Paragraph>
</Content>
</Section>
Dans la solution 2, l'XSD est identique à celui de la solution 3.
Page 40 sur 102
Juillet 2016
10.4.2 signature
Jusque FormPublisher 3.1, il faut ajouter un fragment XSD pour inclure la signature
standard dsig utilisée par eSignBox dans l’XSD du formulaire voici quelques étapes à
suivre :
0) Pas de CDATA
1) Ajouter la partie jaune dans le header du formulaire
2) Importer
le
namespace
lié
au
fichier
XSD
standard
W3C
:
http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-coreschema.xsd (partie bleue) – pas besoin de la schemalocation vu que c’est un
XSD standard W3C
3) Ajouter la partie verte à l’endroit où se trouve la signature dans le suite des
éléments de vos formulaires
4) Valider les XMLs des formulaires signés avec ce nouvel XSD
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:vc="http://www.w3.org/2007/XMLSchema-versioning"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" elementFormDefault="qualified"
attributeFormDefault="unqualified" vc:minVersion="1.1">
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"/>
<xs:element name="FormulaireMIRE">
<xs:annotation>
<xs:documentation>Comment describing your root element</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="Element 1"/>
<xs:element name="Element 2"/>
...
<xs:element ref="ds:Signature"/>
<xs:element name="Element n"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
10.4.3 decimal-integer
Jusque FormPublisher 3.1, il faut ajouter un fragment XSD pour le problème decimalinteger. Dans un dataStore, FormPublisher produit deux formats pour les Doubles (qui
sont déclarés Decimal dans le XSD) :
• le format avec le séparateur de décimales sous forme d'un « . »,
• le format associé aux currency : un point de séparation pour les milliers et une
virgule pour les décimales.
Pour pouvoir prendre en compte cela, il faut une redéfinition du type Decimal couvrant
ces deux formats, en ajoutant le fragment suivant à l'XSD produite par le Studio :


<xs:complexType name="Decimal">
<xs:simpleContent>
<xs:extension base="all_decimal">
<xs:attribute ref="class" use="required" />
Page 41 sur 102
Juillet 2016
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:simpleType name="all_decimal">
<xs:union memberTypes="xs:decimal decimal_currency" />
</xs:simpleType>
<xs:simpleType name="decimal_currency">
<xs:restriction base="xs:string">
<xs:pattern value="[-+]?(\d{1,3}([.]\d{3})*)([,/-]\d{1,2}[€]?)?" />
</xs:restriction>
</xs:simpleType>
*****
Page 42 sur 102
Juillet 2016
Recommandation n° 11. Pré-remplissage
11.1 MÉCANISME
Au début du document jxml, on place l'appel au bloc commun
include_preremplissage_profil.jxml
qui permet de faire le lien entre les variables de l'un des profils (citoyen ou entreprise)
et les variables du formulaire.
Le customizer [jwc] est libre : par exemple « demandeur » est souvent utilisé.
Par contre, derrière, il faut veiller à respecter le nommage repris ci-dessous dans le
mapping de préremplissage : par exemple, une adresse sera toujours nommée [jwc]|
adresse|*.
Le choix entre les 2 profils se fait également dans
include_preremplissage_profil.jxml
en analysant la variable du profil $(TYPESOC).
Recommandation :
Utiliser le bloc commun include_preremplissage_profil.jxml
11.2 MAPPING
DE PRÉREMPLISSAGE
11.2.1 Profil citoyen
Table
portail
Variable portail
Type
variable
PERSPHYS
CIV
PERSPHYS
Valeurs
Variable Jway
Valeurs
VARCHAR2 mr /
mme
[jwc]|identification|civilite
monsieur /
madame
CP
NUMBER
[jwc]|adresse|cp
PERSPHYS
EMAIL
VARCHAR2
[jwc]|telecom|mail
PERSPHYS
FAX
VARCHAR2
[jwc]|telecom|fax
PERSPHYS
GSM
VARCHAR2
[jwc]|telecom|telGsm
PERSPHYS
IDUSER
NUMBER
PERSPHYS
LOCALITE
VARCHAR2
[jwc]|adresse|localite
PERSPHYS
NOM
VARCHAR2
[jwc]|identification|nom
PERSPHYS
NUM
VARCHAR2
[jwc]|adresse|numero
PERSPHYS
PRENOM
VARCHAR2
[jwc]|identification|prenom
PERSPHYS
RUE
VARCHAR2
[jwc]|adresse|rue
PERSPHYS
TEL
VARCHAR2
[jwc]|telecom|tel1
Page 43 sur 102
Juillet 2016
11.2.2 Profil entreprise
Table
portail
Variable portail
Type
variable
SOCIETE
BANQUE_COMPTE
VARCHAR2
[jwc]|banque|
numBancaireBE
SOCIETE
BANQUE_TITUL
VARCHAR2
[jwc]|banque|titulaire|
intitule
SOCIETE
BILAN_DERNIER_EXERCICE
NUMBER
SOCIETE
CA_DERNIER_EXERCICE
NUMBER
SOCIETE
CODE_TYPE_ENTR
VARCHAR2
SOCIETE
DATE_CESSATION
DATE
SOCIETE
DATE_ETAT
DATE
SOCIETE
DATE_IMMATRICULATION_R
C
DATE
SOCIETE
DENOM_ABREV
VARCHAR2
[jwc]|identification|
denominationAbrev
SOCIETE
DENOM_LONG
VARCHAR2
denomination
SOCIETE
DT_CLOTURE
DATE
SOCIETE
DT_DEB_ACT
DATE
SOCIETE
DT_DEMARRAGE
DATE
SOCIETE
ENSEIGN
VARCHAR2
SOCIETE
ETAT
VARCHAR2
SOCIETE
FORM_JUR_ABRE
VARCHAR2
formeJuridiqueAbrev
SOCIETE
FORM_JUR_LONG
VARCHAR2
formeJuridique
SOCIETE
IDUSER
NUMBER
SOCIETE
LIEU_IMMATRICULATION_RC VARCHAR2
SOCIETE
MOTIF_CESSATION
VARCHAR2
SOCIETE
NACE_PRINCIPAL
VARCHAR2
SOCIETE
NACE_SECONDAIRE
VARCHAR2
SOCIETE
NBRE_PERS_ONSS
NUMBER
SOCIETE
NUM_BCE_ENTR
VARCHAR2
SOCIETE
NUM_IMMATRICULATION_RC VARCHAR2
SOCIETE
NUM_ONSS
VARCHAR2
Valeurs
Variable Jway
Valeurs
enseigneCommerciale
[jwc]|identification|numBCE
[jwc]|onss|numero
Page 44 sur 102
Juillet 2016
SOCIETE
NUM_TVA
VARCHAR2
SOCIETE
SIEGE_COMPLT
VARCHAR2
SOCIETE
SIEGE_SOC_BTE
VARCHAR2
[jwc]|adresse|boite
SOCIETE
SIEGE_SOC_CD_INS
VARCHAR2
[jwc]|adresse|ins
SOCIETE
SIEGE_SOC_CD_PAYS
VARCHAR2
SOCIETE
SIEGE_SOC_CD_POST
VARCHAR2
[jwc]|adresse|cp
SOCIETE
SIEGE_SOC_COMMUNE
VARCHAR2
SOCIETE
SIEGE_SOC_EMAIL
VARCHAR2
[jwc]|telecom|mail
SOCIETE
SIEGE_SOC_FAX
VARCHAR2
[jwc]|telecom|fax
SOCIETE
SIEGE_SOC_GSM
VARCHAR2
SOCIETE
SIEGE_SOC_NUM
VARCHAR2
SOCIETE
SIEGE_SOC_RUE
VARCHAR2
[jwc]|adresse|rue
SOCIETE
SIEGE_SOC_TEL
VARCHAR2
[jwc]|telecom|tel1
SOCIETE
SITE_INTERNET
VARCHAR2
[jwc]|telecom|url
SOCIETE
STATUT_ACTUEL
VARCHAR2
SOCIETE
TVA_DATE
DATE
SOCIETE
TVA_LIEU
VARCHAR2
SOCIETE
TVA_N
VARCHAR2
SOCIETE
TYPESOC
VARCHAR2 pers_m
or /
pers_ph
ys
[jwc]|identification|nature
personneMorale/in
dependant
Variable Jway
Valeurs
11.2.3 Profil enseignement
Table
portail
Variable portail
Type
variable
Valeurs
ENSEIGNE
MENT
IDUSER
NUMBER
ENSEIGNE
MENT
TYPE
VARCHAR2
[jwc]|commune|type
ENSEIGNE
MENT
DENOMINATION
VARCHAR2
[jwc]|commune|
denomination
ENSEIGNE
MENT
RUE
VARCHAR2
[jwc]|adresse|rue
ENSEIGNE
MENT
NUM
VARCHAR2
Page 45 sur 102
Juillet 2016
ENSEIGNE
MENT
BTE
VARCHAR2
[jwc]|adresse|boite
ENSEIGNE
MENT
CP
NUMBER
[jwc]|adresse|cp
ENSEIGNE
MENT
LOCALITE
VARCHAR2
ENSEIGNE
MENT
PAYS
VARCHAR2
[jwc]|adresse|pays
ENSEIGNE
MENT
TEL
VARCHAR2
[jwc]|telecom|tel1
ENSEIGNE
MENT
FAX
VARCHAR2
[jwc]|telecom|fax
ENSEIGNE
MENT
EMAIL
VARCHAR2
[jwc]|telecom|mail
ENSEIGNE
MENT
CONTACT_NOM
VARCHAR2
[jwc]|contact|identification|
nom
ENSEIGNE
MENT
CONTACT_PRENOM
VARCHAR2
prenom
ENSEIGNE
MENT
CONTACT_FONCTION
VARCHAR2
[jwc]|contact|employeur|
fonction
ENSEIGNE
MENT
CONTACT_TEL
VARCHAR2
[jwc]|contact|telecom|tel1
ENSEIGNE
MENT
CONTACT_FAX
VARCHAR2
[jwc]|contact|telecom|fax
ENSEIGNE
MENT
CONTACT_GSM
VARCHAR2
[jwc]|contact|telecom|
telGsm
ENSEIGNE
MENT
CONTACT_EMAIL
VARCHAR2
[jwc]|contact|telecom|mail
ENSEIGNE
MENT
CONTACT_CIV
VARCHAR2 mr /
mme
civilite
ENSEIGNE
MENT
NUM_BCE_ENTR
VARCHAR2
ENSEIGNE
MENT
DENOM_LONG
VARCHAR2
denomination
ENSEIGNE
MENT
DENOM_ABREV
VARCHAR2
denominationAbrev
ENSEIGNE
MENT
FORM_JUR_LONG
VARCHAR2
formeJuridique
ENSEIGNE
MENT
FORM_JUR_ABRE
VARCHAR2
formeJuridiqueAbrev
monsieur /
madame
Page 46 sur 102
Juillet 2016
11.2.4 Profil secteur non marchand
Table
portail
Variable portail
Type
variable
Valeurs
Variable Jway
ASBL
IDUSER
NUMBER
ASBL
TYPE
VARCHAR2
[jwc]|commune|type
ASBL
DENOMINATION
VARCHAR2
[jwc]|commune|
denomination
ASBL
RUE
VARCHAR2
[jwc]|adresse|rue
ASBL
NUM
VARCHAR2
ASBL
BTE
VARCHAR2
[jwc]|adresse|boite
ASBL
CP
NUMBER
[jwc]|adresse|cp
ASBL
LOCALITE
VARCHAR2
ASBL
PAYS
VARCHAR2
[jwc]|adresse|pays
ASBL
TEL
VARCHAR2
[jwc]|telecom|tel1
ASBL
FAX
VARCHAR2
[jwc]|telecom|fax
ASBL
EMAIL
VARCHAR2
[jwc]|telecom|mail
ASBL
CONTACT_NOM
VARCHAR2
nom
ASBL
CONTACT_PRENOM
VARCHAR2
prenom
ASBL
CONTACT_FONCTION
VARCHAR2
fonction
ASBL
CONTACT_TEL
VARCHAR2
ASBL
CONTACT_FAX
VARCHAR2
ASBL
CONTACT_GSM
VARCHAR2
telGsm
ASBL
CONTACT_EMAIL
VARCHAR2
ASBL
CONTACT_CIV
VARCHAR2 mr /
mme
civilite
ASBL
NUM_BCE_ENTR
VARCHAR2
ASBL
DENOM_LONG
VARCHAR2
denomination
ASBL
DENOM_ABREV
VARCHAR2
denominationAbrev
ASBL
FORM_JUR_LONG
VARCHAR2
formeJuridique
ASBL
FORM_JUR_ABRE
VARCHAR2
formeJuridiqueAbrev
Valeurs
monsieur /
madame
Page 47 sur 102
Juillet 2016
11.2.5 Profil pouvoir local
Table
portail
Variable portail
Type
variable
Valeurs
Variable Jway
LOC
IDUSER
NUMBER
LOC
TYPE
VARCHAR2
[jwc]|commune|type
LOC
DENOMINATION
VARCHAR2
[jwc]|commune|
denomination
LOC
RUE
VARCHAR2
[jwc]|adresse|rue
LOC
NUM
VARCHAR2
LOC
BTE
VARCHAR2
[jwc]|adresse|boite
LOC
CP
NUMBER
[jwc]|adresse|cp
LOC
LOCALITE
VARCHAR2
LOC
PAYS
VARCHAR2
[jwc]|adresse|pays
LOC
TEL
VARCHAR2
[jwc]|telecom|tel1
LOC
FAX
VARCHAR2
[jwc]|telecom|fax
LOC
EMAIL
VARCHAR2
[jwc]|telecom|mail
LOC
CONTACT_NOM
VARCHAR2
nom
LOC
CONTACT_PRENOM
VARCHAR2
prenom
LOC
CONTACT_FONCTION
VARCHAR2
fonction
LOC
CONTACT_TEL
VARCHAR2
LOC
CONTACT_FAX
VARCHAR2
LOC
CONTACT_GSM
VARCHAR2
telGsm
LOC
CONTACT_EMAIL
VARCHAR2
LOC
CONTACT_CIV
VARCHAR2 mr /
mme
civilite
LOC
NB_HABITANTS
NUMBER
[jwc]|commune|nbHabitants
LOC
NUM_BCE_ENTR
VARCHAR2
LOC
DENOM_LONG
VARCHAR2
denomination
LOC
DENOM_ABREV
VARCHAR2
denominationAbrev
LOC
FORM_JUR_LONG
VARCHAR2
formeJuridique
Valeurs
monsieur /
madame
Page 48 sur 102
Juillet 2016
LOC
FORM_JUR_ABRE
VARCHAR2
formeJuridiqueAbrev
11.2.6 Profil tiers
Table
portail
Variable portail
Type
variable
Valeurs
Variable Jway
TIERS
IDUSER
NUMBER
TIERS
TYPE
VARCHAR2
[jwc]|commune|type
TIERS
DENOMINATION
VARCHAR2
[jwc]|commune|
denomination
TIERS
CONTACT_NOM
VARCHAR2
nom
TIERS
CONTACT_PRENOM
VARCHAR2
prenom
TIERS
CONTACT_FONCTION
VARCHAR2
fonction
TIERS
CONTACT_TEL
VARCHAR2
TIERS
CONTACT_FAX
VARCHAR2
TIERS
CONTACT_GSM
VARCHAR2
telGsm
TIERS
CONTACT_EMAIL
VARCHAR2
TIERS
CONTACT_CIV
VARCHAR2 mr /
mme
civilite
TIERS
NUM_BCE_ENTR
VARCHAR2
TIERS
DENOM_LONG
VARCHAR2
denomination
TIERS
DENOM_ABREV
VARCHAR2
denominationAbrev
TIERS
SIEGE_SOC_RUE
VARCHAR2
[jwc]|adresse|rue
TIERS
SIEGE_SOC_NUM
VARCHAR2
TIERS
SIEGE_SOC_BTE
VARCHAR2
[jwc]|adresse|boite
TIERS
SIEGE_COMPLT
VARCHAR2
TIERS
SIEGE_SOC_CD_PAYS
VARCHAR2
TIERS
SIEGE_SOC_CD_POST
VARCHAR2
[jwc]|adresse|cp
TIERS
SIEGE_SOC_COMMUNE
VARCHAR2
TIERS
SIEGE_SOC_CD_INS
VARCHAR2
[jwc]|adresse|ins
TIERS
SIEGE_SOC_PAYS
VARCHAR2
[jwc]|adresse|pays
Valeurs
monsieur /
madame
Page 49 sur 102
Juillet 2016
TIERS
SIEGE_SOC_TEL
VARCHAR2
[jwc]|telecom|tel1
TIERS
SIEGE_SOC_FAX
VARCHAR2
[jwc]|telecom|fax
TIERS
SIEGE_SOC_EMAIL
VARCHAR2
[jwc]|telecom|mail
TIERS
FORM_JUR_ABRE
VARCHAR2
formeJuridiqueAbrev
TIERS
FORM_JUR_LONG
VARCHAR2
formeJuridique
TIERS
TYPESOC
VARCHAR2
11.2.7 Profil fonctionnaire
Table
portail
Variable portail
Type
variable
Valeurs
Variable Jway
AGENT
AGENT_IDUSER
NUMBER
AGENT
AGENT_NOM
VARCHAR2
AGENT
AGENT_PRENOM
VARCHAR2
AGENT
AGENT_DETAIL
VARCHAR2
AGENT
AGENT_TEL_PRO
VARCHAR2
AGENT
AGENT_ID_ADMIN
VARCHAR2
AGENT
AGENT_CIVILITE
VARCHAR2 mr /
mme
AGENT
AGENT_GRADE
VARCHAR2
[jwc]|identification|grade
AGENT
AGENT_STATUT
VARCHAR2
[jwc]|identification|statut
AGENT
AGENT_FONCTION
VARCHAR2
[jwc]|identification|fonction
AGENT
AGENT_INSTITUTION
VARCHAR2
[jwc]|employeur|institution
AGENT
AGENT_DIR_GEN
VARCHAR2
[jwc]|employeur|dg
AGENT
AGENT_DIRECTION
VARCHAR2
[jwc]|employeur|direction
AGENT
AGENT_DEPARTEMENT
VARCHAR2
[jwc]|employeur|
departement
AGENT
AGENT_SERVICE
VARCHAR2
[jwc]|employeur|employeur
AGENT
AGENT_EMAIL_PRO
VARCHAR2
[jwc]|employeur|telecom|
mail
AGENT
AGENT_TEL_PERSO
VARCHAR2
[jwc]|telecom|tel1
AGENT
AGENT_EMAIL_PERSO
VARCHAR2
[jwc]|telecom|mail
AGENT
AGENT_COMPTE
VARCHAR2
[jwc]|banque|
numBancaireBE
Valeurs
[jwc]|employeur|telecom|
tel1
monsieur /
madame
Page 50 sur 102
Juillet 2016
11.3 TABLEAU
RÉCAPITULATIF DU MAPPING SELON LES
7
PROFILS
Tiers
Pouvoir public
Citoyen
Enseignement
Asbl
Agent
Entreprise
AGENT_CIVILITE
x
AGENT_COMPTE
x
[jwc]|banque|numBancaireBE
AGENT_DEPARTEMENT
x
[jwc]|employeur|departement
AGENT_DETAIL
x
AGENT_DIR_GEN
x
[jwc]|employeur|dg
AGENT_DIRECTION
x
[jwc]|employeur|direction
AGENT_EMAIL_PERSO
x
[jwc]|telecom|mail
AGENT_EMAIL_PRO
x
[jwc]|employeur|telecom|mail
AGENT_FONCTION
x
[jwc]|identification|fonction
AGENT_GRADE
x
[jwc]|identification|grade
AGENT_ID_ADMIN
x
AGENT_IDUSER
x
AGENT_INSTITUTION
x
[jwc]|employeur|institution
AGENT_NOM
x
AGENT_PRENOM
x
AGENT_SERVICE
x
[jwc]|employeur|employeur
AGENT_STATUT
x
[jwc]|identification|statut
AGENT_TEL_PERSO
x
[jwc]|telecom|tel1
AGENT_TEL_PRO
x
[jwc]|employeur|telecom|tel1
DENOMINATION
x
x
x
NB_HABITANTS
x
x
TYPE
x
x
BTE
x
x
CIV
x
x
x
x
[jwc]|commune|denomination
[jwc]|commune|nbHabitants
x
[jwc]|commune|type
[jwc]|adresse|boite
CP
x
x
x
x
[jwc]|adresse|cp
EMAIL
x
x
x
x
[jwc]|telecom|mail
FAX
x
x
x
x
[jwc]|telecom|fax
GSM
LOCALITE
NOM
x
x
x
x
x
x
Page 51 sur 102
Juillet 2016
Enseignement
Citoyen
Pouvoir public
x
x
x
x
PAYS
x
x
x
x
[jwc]|adresse|pays
PRENOM
Tiers
Asbl
Agent
Entreprise
NUM
x
RUE
x
x
x
x
[jwc]|adresse|rue
TEL
x
x
x
x
[jwc]|telecom|tel1
BANQUE_COMPTE
x
[jwc]|banque|numBancaireBE
BANQUE_TITUL
x
[jwc]|banque|titulaire|intitule
BILAN_DERNIER_EXERCICE
x
CA_DERNIER_EXERCICE
x
CODE_TYPE_ENTR
x
CONTACT_CIV
x
x
x
x
x
[jwc]|contact|identification|civilite
CONTACT_EMAIL
x
x
x
x
x
CONTACT_FAX
x
x
x
x
x
CONTACT_FONCTION
x
x
x
x
x
[jwc]|contact|employeur|fonction
CONTACT_GSM
x
x
x
x
x
[jwc]|contact|telecom|telGsm
CONTACT_NOM
x
x
x
x
x
[jwc]|contact|identification|nom
CONTACT_PRENOM
x
x
x
x
x
[jwc]|contact|identification|prenom
CONTACT_TEL
x
x
x
x
x
DATE_CESSATION
x
DATE_ETAT
x
DATE_IMMATRICULATION_RC
x
DENOM_ABREV
x
x
x
x
x
denominationAbrev
DENOM_LONG
x
x
x
x
x
[jwc]|identification|denomination
DT_CLOTURE
x
DT_DEB_ACT
x
DT_DEMARRAGE
x
ENSEIGN
x
ETAT
x
FORM_JUR_ABRE
x
x
x
x
x
formeJuridiqueAbrev
FORM_JUR_LONG
x
x
x
x
x
[jwc]|identification|formeJuridique
enseigneCommerciale
Page 52 sur 102
Juillet 2016
Pouvoir public
Tiers
Enseignement
x
Citoyen
Asbl
Agent
Entreprise
x
x
x
LIEU_IMMATRICULATION_RC
x
MOTIF_CESSATION
x
NACE_PRINCIPAL
x
NACE_SECONDAIRE
x
NBRE_PERS_ONSS
x
NUM_BCE_ENTR
x
NUM_IMMATRICULATION_RC
x
NUM_ONSS
x
NUM_TVA
x
SIEGE_COMPLT
x
x
SIEGE_SOC_BTE
x
x
[jwc]|adresse|boite
SIEGE_SOC_CD_INS
x
x
[jwc]|adresse|ins
SIEGE_SOC_CD_PAYS
x
x
SIEGE_SOC_CD_POST
x
x
[jwc]|adresse|cp
SIEGE_SOC_COMMUNE
x
x
SIEGE_SOC_EMAIL
x
x
[jwc]|telecom|mail
SIEGE_SOC_FAX
x
x
[jwc]|telecom|fax
SIEGE_SOC_GSM
x
SIEGE_SOC_NUM
x
x
SIEGE_SOC_PAYS
x
x
[jwc]|adresse|pays
SIEGE_SOC_RUE
x
x
[jwc]|adresse|rue
SIEGE_SOC_TEL
x
x
[jwc]|telecom|tel1
SITE_INTERNET
x
STATUT_ACTUEL
x
TVA_DATE
x
TVA_LIEU
x
TVA_N
x
TYPESOC
x
IDUSER
x
[jwc]|onss|numero
[jwc]|telecom|url
x
x
x
x
x
x
*****
Page 53 sur 102
Juillet 2016
Recommandation n° 12. Layout
12.1 DÉFINITION
Le layout en cours est appelé « L3 » (3e version du layout web+pdf des formulaires
électroniques chez eWBS, après « L1 » et « L2A »).
Il est complètement inclus dans les templates, donc dans @COMMUN.
Recommandation :
Il ne faut pas vouloir modifier les aspects graphiques de présentation de façon
ponctuelle sur un projet de formulaire.
→ Toujours laisser faire le layout.
C'est malgré tout très faisable (au moyen de l'APPLI.REF), mais cela engendre
beaucoup de problèmes d'efficacité de développement ou de mise à jour, et
surtout, de cohérence pour l'usager.
Règle d'or
L'usage d'un layout particulier défini dans l'APPLI.REF est à éviter au
maximum.
12.2 LAYOUT
DES
RADIOBOX
Les RadioBox doivent être alignés verticalement
<RadioBox OptionsPerLine="1">
➔ Pour éviter la confusion : si les libellés des options sont sur la même ligne, on
peut hésiter entre le bouton à gauche du libellé et le bouton à droite.
➔ Pour une question ergonomique : rapidement associer visuellement le nombre
d'options, qui doivent donc être les plus rapprochées possible pour former un
groupe.
Exemples :
O oui O non
Confus pour le « oui » : doit-on cocher à
droite ou à gauche du « oui » ?
O oui
O non
Plus clair
Page 54 sur 102
Juillet 2016
O habitation O appartement
O tente O caravane
O
O
O
O
O
habitation
appartement
chalet
tente
caravane
O chalet
On ne voit pas d'un coup d’œil qu'il y a 5
options
On associe directement d'un coup d'oeil
les 5 options dans un seul groupe
Recommandation :
Pour les RadioBox, on utilise <RadioBox OptionsPerLine="1">.
*****
Page 55 sur 102
Juillet 2016
Recommandation n° 13. Nouveau projet
13.1 COMMENT
DÉMARRER UN NOUVEAU PROJET
?
Recommandation :
Utiliser EASI_ZeroVierge dans Subversion qui contient toutes les rubriques
possibles.
*****
Page 56 sur 102
Juillet 2016
Recommandation n° 14. Rubriques de renseignements
14.1 PRINCIPE
Les rubriques de renseignements sont censées fournir les informations utiles à
l'usager lors du remplissage en ligne.
Groupe
Titre
Description
MetaContent / MetaField / fichier
Pour quoi ?
<MetaContent Type="subject">
Public
Pour qui ?
<MetaContent Type="target">
Avantages
Combien ?
<MetaContent Type="advantages">
Conditions
Comment ?
<MetaContent Type="conditions">
Description Objet
Aide
Réglementation Base légale
<MetaContent Type="legal">
Administration
émettrice
Administration
responsable du
formulaire
<MetaFields Name="organisation">
Contacts
Qui contacter à
l'administration
responsable du
formulaire ?
<MetaContent Type="contact">
Instructions
Page menu
rassemblant toutes
les instructions
(BC) xinstructions_default.jxml
Instructions
pour le
remplissage
Instructions
pendant le
remplissage du
formulaire
(BC)
xinstructions_remplissage_defaul
t
Instructions
pour
l'Enregistremen
t
Instructions après
avoir cliqué sur le
bouton « Valider »
de la dernière page
du formulaire
(BC)
xinstructions_enregistrement_def
ault.jxml
Instructions
pour la
Signature
Instructions après
avoir cliqué sur le
bouton
« Enregistrer »
(BC)
xinstructions_signature_default
Instructions
pour la
Instructions après
avoir choisi la
(BC)
xinstructions_finalisation_defau
Page 57 sur 102
Juillet 2016
Groupe
Titre
Description
Finalisation
signature
lt
Formulaire
papier
(formulaire.pdf)
Glossaire
index_glossary.jxml
FAQ
xfaq.jxml
Traitement Procédure
administrative
Vie privée
Recours
Recours
particulier
Médiateur
<MetaContent Type="process">
comment sont
traitées les données
par l'administration,
(BC) xvie_privee.jxml
jusqu'à la
décision,
notamment dans le
respect de la Loi Vie
privée
après la décision, <MetaContent Type="appeal">
que peut-on faire si
on n'est pas
(BC)xmediateur.jxml
d'accord
Une rubrique est la page de validation en fin du processus de remplissage du
formulaire électronique. Le contenu de cette page correspond exactement au contenu
de la page
Description
Page de validation
Page contenant le
bouton « Valider »
(BC)xvalidation_default.jxml
Certaines de ces rubriques sont reprises dans la première page du pdf.
Description
Introduction pour le contact
<MetaContent Type="contactintroduction">
Instructions pour le papier
<MetaContent Type="instructionsfor-paper">
Adresse postale dans le cadre si celle-ci doit être <MetaContent
Type="PostReturnAddress">
différente de l'administration émettrice
(<MetaFields Name="organisation">)
en bleu → dans le fichier xatoms.jxml
Page 58 sur 102
Juillet 2016
en vert → dans le fichier xcommon.jxml
Recommandation à propos de la personne de contact :
Il faut toujours faire figurer les renseignements suivants lorsqu'on mentionne une
personne de contact :
→ civilité : « M. » ou « Mme » car il est possible que le prénom ne permette pas
de fixer le genre de la personne, ce qui peut mettre mal à l'aise l'usager
→ prénom en minuscules, nom en majuscule pour distinguer les noms qui
ressemblent à des prénoms
→ téléphone, marqué « Tél. : » et le numéro en notation IBPT
On peut y ajouter :
→ un titre (Directeur par exemple)
→ une adresse courriel
→ le fax
→ le site web
→ etc.
*****
Page 59 sur 102
Juillet 2016
Recommandation n° 15. Ordre des sections
15.1 ORDRE
STANDARD
eWBS impose de respecter au mieux l'ordre standard des sections.
Objectif de la standardisation de l'ordre des sections
Permettre aux usagers qui utiliseront plusieurs formulaires différents de retrouver
toujours la même trame, le même ordre, la même structure, autant que possible.
Éviter que le rédacteur traite les contenus similaires de façon trop hétéroclite.
Une de ces sections peut être facultative, mais l'ordre et l'intitulé doivent être
respecté, sauf si contre-indication spécifique et explicite de l'équipe des experts en
lisibilité.
N°
Titre exact de la section
1
« Coordonnées du demandeur »
1.1 « Identification du demandeur »
Explication
il s'agit
•
soit du N° national ou nomprénom pour une personne,
•
soit du numéro d'entreprise
1.2 « Adresse du demandeur » ou
« Siège social »
1.3 « Unités d'établissement »
uniquement s'il s'agit d'une entreprise
1.4 « Contact »
1.5 « Compte bancaire »
2
Objet(s) de la demande (travaux, données techniques, etc.)
3
...
n
n+1 « Liste des documents à joindre »
n+2 « Déclaration sur l'honneur et
signature »
n+3 « Protection de la vie privée et voies de (gosub_mediateur_vie_privee.jxml) –
Page 60 sur 102
Juillet 2016
recours »
Si la mention « médiateur » ne doit
pas être placée (rare!), on utilise le
titre « Protection de la vie privée »
(gosub_vie_privee.jxml)
n+4 « Enquête de satisfaction »
15.2 TYPES
(gosub_enquete_satisfaction.jxml)
DE SECTION
Les types de <Section> possibles sont : Type="standard",
Type="appendice", Type="article", Type="landscape".
•
•
•
•
Type="preface",
"preface" = section non numérotée en début de formulaire, à mettre avant
toute section
"appendice" = section non numérotée en fin de formulaire, à mettre après toute
section
"article" = ???
"landscape" = section sur une page en mode paysage
Si titre <Title> trop long dans une <Section> → problème scroll horizontal ET/OU de
MAP
→ si problème de scroll horizontal → raccourcir le titre (lisibilité ou administration
responsable) + ajouter un paragraphe introductif de description reprenant le titre long
en entier
→ si problème de MAP → pour éviter cela, mettre un titre plus court en utilisant un
<ShortTitle>
*****
Page 61 sur 102
Juillet 2016
Recommandation n° 16. Liste des documents à joindre
16.1 PRINCIPE
Tout est dans le MY.REF : on utilise 4 blocs communs et on pose la variable
« uploadable » dans APPLI.REF/publication.properties.
easi.form.uploadable=ENABLED
Pour que tous les documents à joindre soient sans la possibilité d'uploader, il faut
mettre
easi.form.uploadable=DISABLED
et ne rien changer d'autre dans le formulaire identique.
Recommandation :
Il FAUT que le <Title> de la section appelante soit « Liste des documents à
joindre ».
Recommandation importantissime !!!
Il FAUT que l'Id de la section appelante soit "depotDocuments", au
caractère près.
NB : L'Id de la section d'où sont uploadés les document à joindre est envoyé par une
fonction du portail dans la DB des demandes soumises, variable « CONTEXT ». Une
erreur dans cet Id peut entraîner que les usagers ne retrouvent pas leurs documents
joints.
16.2 ATTACHMENTBOX
L'objet <AttachmentBox> prévu dans FormPublisher n'est pas encore utilisé. Et n'est
pas à utiliser.
16.3 BLOCS
COMMUNS UTILISÉS
include_folder/include_annexe_DEBUT.jxml
include_folder/include_annexe_FIN.jxml
include_folder/include_annexe_LIGNE.jxml
include_folder/include_annexe_CIBLE.jxml
16.4 CUSTOMIZERS
Ces customizers sont obligatoires.
include_annexe_DEBUT.jxml
Page 62 sur 102
Juillet 2016
•
[label] pour l'intitulé avant les annexe
•
[annexeMaxNumber] pour le nombre maximum d'annexes, permet de charger
autant
de
variables
anx01,
anx02,
anx03,
anx04,
etc.
→ si
annexeMaxNumber="3" alors cela crée les variables suivantes : anx01, anx02,
anx03. Même si c'est pour n'utiliser que anx01 et anx03...
dans l'onglet XML
<Include NewPage="none" DocumentId="include_annexe_DEBUT">
<Customizer Name="[annexeMaxNumber]" Value="15" />
<Customizer Name="[label]" Value=" " />
</Include>
include_annexe_FIN.jxml
•
[annexeMaxNumber] idem que pour le DEBUT
dans l'onglet XML
<Include NewPage="none" DocumentId="include_annexe_FIN">
</Include>
include_annexe_LIGNE.jxml
•
[jwc] pour le nommage des variables (exemple : [jwc]="anx04")
•
[mandatory] =true pour un document obligatoire ; = false sinon
•
[label] pour l'intitulé du document demandé
ATTENTION ! le label ne peut pas contenir de balise, donc par exemple, pas de
gras, ou d'hyperlien. Se reporter à la section « Cas d'un label spécial » cidessous.
dans l'onglet XML
<Include NewPage="none" DocumentId="include_annexe_LIGNE">
<Customizer Name="[label]" Value="Document à annexer" />
<Customizer Name="[mandatory]" Value="false" />
<Customizer Name="[jwc]" Value="anx12" />
</Include>
include_annexe_CIBLE.jxml
•
[label] pour l'intitulé du groupe cible
dans l'onglet XML
<Include NewPage="none" DocumentId="include_annexe_CIBLE">
<Customizer Name="[label]" Value="Pour tous (personnes physiques ET
morales)" />
</Include>
Page 63 sur 102
Juillet 2016
16.5 EXEMPLE
Rem : les customizers anx01, anx02, anx03, etc. ne doivent pas nécessairement être
dans l'ordre, ni même être tous utilisés.
<section id="depotDocuments" newpage="true">
<title>Liste des documents à joindre</title>
<Include NewPage="none" DocumentId="include_annexe_DEBUT">
<Customizer Name="[label]" Value=" " />
</Include>
<Include NewPage="none" DocumentId="include_annexe_CIBLE" IsVisible="$
(constitutionEntreprise)=='PHYSIQUE'">
<Customizer Name="[label]" Value="Pour les personnes physiques" />
</Include>
<Include NewPage="none" DocumentId="include_annexe_LIGNE" IsVisible="$
(constitutionEntreprise)=='PHYSIQUE'">
<Customizer Name="[label]" Value="Copie du contrat" />
</Include>
<Include NewPage="none" DocumentId="include_annexe_CIBLE" IsVisible="$
(constitutionEntreprise)=='MORALE'" mode="report">
<Customizer Name="[label]" Value="Pour les personnes physiques" />
</Include>
(constitutionEntreprise)=='MORALE'">
</Include>
(constitution Entreprise)=='MORALE'">
</Include>
<Include NewPage="none" DocumentId="include_annexe_FIN">
</Include>
</section>
Remarque 1 : mode report sur les CIBLEs.
Remarque 2 : test sur un document à joindre
16.6 CAS D'UN
LABEL SPÉCIAL
Le [label] étant un customizer, donc la valeur d'un attribut xml, il n'est pas possible de
lui passer un hyperlien ou un style (bold ou italic). Nous sommes alors dans le cas
d'un « label spécial ».
Pour contourner le problème, il faut diviser le libellé du document à joindre en deux :
Page 64 sur 102
Juillet 2016
1. une expression courte sans hyperlien, sans style bold, va dans le customizer,
2. une explication complémentaire est placée dans un petit paragraphe explicatif
dans un <td type="emphase">.
Cette explication complémentaire doit être placée dans un petit tableau de mise en
disposition dont les colonnes ont les mêmes largeurs que dans le bloc commun
include_annexe_LIGNE, càd 3% et 97%.
Il ne faut pas oublier de reprendre la condition éventuelle de l'<include> sur le
<Content>.
Dans l'exemple ci-dessous, l'hyperlien en rouge ne peut pas être placé dans le
customizer [label]. On doit donc ajouter un <Content>.
<include customizer="anx02" edoc="commun/include_annexe_LIGNE.png"
test="$( travaux|realisationSansEntrepreneur )=='non'">
<customizer name="[label]">Le document « Annexe technique 1 Isolation du toit d'un bâtiment » à faire remplir par
l'entrepreneur.</customizer>
<customizer name="[mandatory]">true</customizer>
</include>
<Content test="$( travaux|realisationSansEntrepreneur )=='non'">
<table type="sansBordures">
<columnDefinitions>
<columnDefinition width="3%" />
<columnDefinition width="97%" />
</columnDefinitions>
<tr>
<td></td>
<td type="emphase">
<p>Ce document est disponible en ligne sur le site
<url relation="external" url="http://energie.wallonie.be">
http://energie.wallonie.be</url>
ou au <dlink codoc="annexe01" ids="draftData" mode="Report"
relation="external" type="pdf" usage="court">format
papier</dlink>.</p>
</td>
</tr>
</table>
</Content>
*****
Page 65 sur 102
Juillet 2016
Recommandation n° 17. Enquête de satisfaction
17.1 PRINCIPE
DE BASE
Le questionnaire de satisfaction a été révisé par la lisibilité en août 2011 (pour mieux
prendre en compte les aspects informatisation/dématérialisation).
Recommandation
L'enquête de satisfaction doit figurer dans TOUS les formulaires, SAUF exceptions
précisées dans la liste ci-dessous
17.2 EXCEPTIONS
•
si le formulaire qui ne fait qu'une seule page, c'est-à-dire ceux de la liste
exhaustive suivante :
Examen de chasse
•
les formulaires pour lesquels l'administration (ou l'expert en lisibilité) a
explicitement exigé qu'il ne figure pas, c'est-à-dire ceux de la liste exhaustive
suivante :
Déclaration des mandats
exigence de la Cellule de déclaration des
mandats (M. Nicole MATAGNE)
Pôle de compétitivité
formulaires annexes un peu particuliers
(car coexistence formulaire word avec
annexes électroniques) dans lesquel il
n'est pas opportun d'ajouter l'enquête
Test Kafka
pas vraiment un formulaire mais un outil
de décision
Envoi recommandé
Questionnaire évaluant la pertinence de
l'utilisation d'un envoi recommandé
*****
Page 66 sur 102
Juillet 2016
Recommandation n° 18. Voies de recours et vie privée
18.1 BLOCS
COMMUNS À UTILISER
xvie_privee pour l'affichage de la mention « Vie privée » dans les onglets de
Renseginement
<Include NewPage="none" DocumentId="xvie_privee">
<Customizer Name="[labelDirection]" Value="Direction générale opérationnelle
de l'Aménagement du Territoire, du Logement, du Patrimoine et de l'Énergie" />
</Include>
include_mediateur pour l'affichage de la mention « Voie de recours » dans les onglets
de Renseginement
<Include NewPage="none" DocumentId="xmediateur" />
gosub_mediateur_vie_privee pour l'affichage des 2 mentions en pdf
<Section OutputMode="report" NewPage="both" Type="standard">
<Title>Protection de la vie privée et voies de recours</Title>
<Include NewPage="none" DocumentId="gosub_mediateur_vie_privee">
<Customizer Name="[labelDirection]" Value="Direction générale opérationnelle
de l'Aménagement du Territoire, du Logement, du Patrimoine et de l'Énergie" />
</Include>
</Section>
gosub_vie_privee pour l'affichage en pdf si la mention médiateur n'est pas exigée
<Section OutputMode="report" NewPage="screen" Type="standard">
<Title>Protection de la vie privée</Title>
<Include NewPage="none" DocumentId="gosub_vie_privee">
<Customizer Name="[labelDirection]" Value="Direction Générale de
l'Agriculture, des Ressources naturelles et de l'Environnement" />
</Include>
</Section>
Recommandation :
Le titre de la section contenant l'appel au gosub doit être « Protection de la vie
privée et voies de recours » (ou « Protection de la vie privée » dans le
second cas)
*****
Page 67 sur 102
Juillet 2016
Recommandation n° 19. Typographie
19.1 PRINCIPE
eWBS impose le respect strict de règles typographiques.
Objectifs des règles typographiques
Montrer une image sérieuse de la Wallonie, de respect de la langue utilisée.
Garantir une certaine harmonie et une cohérence dans la présentation pour
l'usager.
19.2 TABLEAU
SYNTHÉTIQUE DES RECOMMANDATIONS
Ce tableau reprend une partie des règles de typographie. Cette liste n'est pas
exhaustive : elle a simplement pour but d'attirer l'attention du rédacteur sur les points
les plus importants et/ou les plus courants. Pour l'exhaustivité, cf. section 19.3 cidessous.
N° Recommandation / convention
1 Pas de titre en toutes majuscules, ce sont les
feuilles de style qui gèrent la mise en majuscule
éventuelle.
Exemples
Réf.
Titre comme ceci
TITRE PAS COMME
CELA
****
2 Selon les règles de la typographie française, pour « Une citation
les guillemets français, toujours « et » jamais " et valide »
". Au clavier ALT+0171 et ALT+0187
et non
"Comme ceci"
*
3 Par convention, on écrira toujours « € » (dans un 200 €
tableau) ou « euro » et « euros » (dans du texte), 200 euros dans du
mais pas « EUR » ou « EURO » ou « Euro »
texte
et non
200 EUR ou 200
Euros
****
4 Selon les règles de la typographie française,
toujours les accents sur les majuscules !!!
ALT+0201
*
Étant donné que...
À l'avenir, ils...
Page 68 sur 102
Juillet 2016
5 Par convention, on remplace les blancs par un
« blanc insécable » (en théorie une « espace fine
insécable ») devant certains caractères de
ponctuation ou dans certains cas pour éviter un
saut de ligne intempestif devant ces
caractères.
En l'occurrence :
• avant les «_: » et les «_; »,
• entre la date et le mois,
• dans un nombre comme séparateur de
milliers,
• sauf en dessous de 10 000,
• entre un nombre et les unités de mesure,
• dans les numéros de téléphone
En pratique, on insère un CTRL+SPACE en mode
« FLOW » dans FormPublisherStudio, et  
(non breaking space) en mode texte.
Exemples
Réf.
> Voici la liste_:
> le 25_février 2007
> 4_500_000,00
*
****
*
> 1987, 5165,67
*
> 35_km, 450_euros *
> 081_11_22_33
***
6 Listes à puce ou listes numérotées (3 cas
distincts, majuscule ou minuscule après la puce,
« , » ou « ; » ou « . » à la fin de la puce) :
• énumération de mots (substantifs) →
minuscule et « , »
• énumération de phrases seules avec verbe
→ minuscule et « ; »
• énumération de paragraphes (groupes de
phrases) → majuscule et « . »
Il n'est pas cohérent d'avoir une liste à puces avec
un mélange de mots d'une part, et de phrases ou
de paragraphes d'autre part.
Si des phrases seules et des paragraphes sont
dans la même liste à puces, on considère le cas
« paragraphe » → majuscule et « . »
7 Pour les numéros de téléphone, on sépare par
081_11_22_33
des « blancs insécables » (CTRL+SPACE en mode et non
« FLOW » dans FormPublisherStudio,) entre les
081/11.22.33
nombres, et non des « . », des « - » ou des « / ».
*
**
Pour les numéros de téléphone internationaux, on +32_81_11_22_33
note le « + » devant le code du pays.
***
Page 69 sur 102
Juillet 2016
8 TOUJOURS écrire les url de la même manière,
avec le protocole en tête.
TOUJOURS écrire les adresses courriel, on écrit
sans aucune majuscule.
9 Par convention les sigles abrégés en majuscules,
sans point.
Selon les règles de la typographie française,
ATTENTION aux sigles en toutes lettres, pas de
majuscules pour un adjectif.
Exemples
Réf.
http://www.wallonie. ****
be
et non
www.wallonie.be
****
prenom.nom@machi
n.be
et non
Prenom.Nom@Machi
n.be
OCDE ou SPW
et non
O.C.D.E. ou S.P.W.
*
SPW = Service public
de Wallonie avec
petit « p »
ASE = Agence de
Stimulation
économique
10 Par convention, nom de famille en majuscules
M. Michel FRANÇOIS
(pour éviter la confusion nom-prénom éventuelle) et non
et ne jamais mettre un nom sans la civilité (M. ou M. Michel François
Mme).
****
11 Selon les règles de la typographie française, en
abrégé, on écrit
Monsieur = M.
Madame = Mme
Mademoiselle = Mlle
Messieurs = MM.
Docteur = Dr
premiers = 1ers
deuxièmes = 2es
etc.
M., Mme, MM., Mlle,
Dr, 1ers, 2es, etc.
et non
Mr, 2èmes, etc.
*
12 Par convention, nom de ville en minuscules.
Liège
et non
LIÈGE
****
19.3 SOURCES
DES RECOMMANDATIONS TYPOGRAPHIQUES
Les recommandations sont :
• soit reprises des règles de la typographie française (*), http://www.dsi.univparis5.fr/typo.html, extraites du Manuel de typographie française élémentaire
d'Yves Perrousseaux, lui-même inspiré des Règles typographiques en usage à
Page 70 sur 102
Juillet 2016
•
•
•
l'Imprimerie nationale (ISBN 2-11-081075-0) ou du Dictionnaire des règles
typographiques de Louis Géry, CFPJ Editions ;
soit reprises du Code de rédaction interinstitutionnel, obligatoire pour tout
intervenant dans l'élaboration de tout type de document (papier ou
électronique) au sein des institutions, organes et services de l'Union
européenne (**) ;
soit reprises de la norme IBPT (***) ;
soit le fruit d'une convention interne chez eWBS, dans un soucis de bon sens et
de cohérence (****).
*****
Page 71 sur 102
Juillet 2016
Recommandation n° 20. Dénominations et logos officiels
Recommandation :
En accord avec la Direction de la Communication, les dénominations et logos
officiels doivent être utilisés. Jamais les raccourcis DGO1, etc.
20.1 DÉNOMINATIONS
OFFICIELLES
Comme convenu avec la Direction de la Communication (réunion du 22 juin 2009 et
charte graphique publiée sur son site, cf. http://chartegraphique.wallonie.be),
TOUJOURS écrire les DG de la même manière dans le texte, c'est-à-dire en toutes
lettres et JAMAIS en abrégé :
toujours
remplacer
...
par
...
SG → Secrétariat général
DGT
→ Direction générale transversale du
Budget, de la Logistique et des
Technologies de l’information et de
la communication
et en allemand, par
...
Secretariat-Generaal
Ressortübergreifende
Generaldirektion für Haushalt,
Logistik und Informationsund
Kommunikationstechnologie
DGO1 → Direction générale opérationnelle
des Routes et des Bâtiments
Operative Generaldirektion für
Strassen und Gebäude
de la Mobilité et des Voies
hydrauliques
Mobilität und Wasserweg
de l'Agriculture, des Ressources
naturelles et de l'Environnement
Landwirtschaft Naturschätze und
Umwel
de l'Aménagement du Territoire,
du Logement, du Patrimoine et de
l'Énergie
Raumordnung, Wohnungswesen,
Erbe und Energie
des Pouvoirs locaux, de l'Action
sociale et de la Santé
Lokale Behörden, Soziale
Massnahmen und Gesundheit
de l'Économie, de l'Emploi et de la Unternehmen, Beschäftigung und
Recherche
Forschung
Page 72 sur 102
Juillet 2016
de la Fiscalité
Steuerwesen
En xml, pour l'adresse du formulaire dans le cadre à droite (première page du
formulaire), on mettra :
<MetaFields Name="organisation">
<MetaField Name="name">Service public de Wallonie</MetaField>
<MetaField Name="department1">Direction générale opérationnelle de
l'Agriculture des Ressources naturelles et de l'Environnement</MetaField>
<MetaField Name="department2">Département de la Nature et des
Forêts</MetaField>
<MetaField Name="department3">Direction de la Chasse et de la
Pêche</MetaField>
<MetaField Name="department4">Servie Untel</MetaField>
<MetaField Name="address-line1">Chaussée de Charleroi, 83 B</MetaField>
<MetaField Name="zip-code">5000</MetaField>
<MetaField Name="city">Salzinnes (Namur)</MetaField>
</MetaFields>
Attention, c'est « O » comme « opérationnelle » et non zéro !
20.2 LOGOS
OFFICIELS
Comme convenu avec la Direction de la Communication (réunion du 22 juin 2009 et
charte graphique, cf. http://chartegraphique.wallonie.be/CHARTE_SPW_1_7.pdf),
• le logo de la Wallonie se place en haut à gauche,
• le logo de l'entité (SPW pour le Service public de Wallonie, logo spécifique pour
les OIP) se place en haut à droite.
*****
Page 73 sur 102
Juillet 2016
Recommandation n° 21. Recommandations de lisibilité
Recommandation :
Suivre les 10 règles d'or de la lisibilité.
Ce document est disponible sur demande.
*****
Page 74 sur 102
Juillet 2016
Recommandation n° 22. Principes de mise en page
Principe général
Minimiser la mise en page, laisser faire les feuilles de style au maximum.
En particulier :
1. Essayer de regrouper les éléments en <Content> et en <Paragraph> pour
structurer les données d'après leur sens et non pas pour mettre en page.
ATTENTION ! <Content> ajoute un interligne avant et après, <Paragraph> pas.
2. Utiliser
les
<Content>
StyleName="warning"
StyleName="remark"
StyleName="important" pour remplacer des phrases du type « Remarque » ou
« Attention, vous trouverez l'info ... ». Ce type de <Content> peut ajouter (ou
pas) un logo adéquat, mais de toute façon, ce logo doit être fixé par les
templates et les feuilles de style.
3. Pour insérer un interligne supplémentaire, si vraiment c'est indispensable. Où ?
À la fin d'un <Content> et non au début. Comment ?
<Content>
<Paragraph
</Content >
Spacing="x-large">blablabla</Paragraph>
4. Éviter les <table> autant que possible pour faire de la mise en page ; par
exemple, pour faire une liste, on utilise préférentiellement <List
MarkerStyle="number">
pour
une
liste
numérotée
ou
<List
MarkerStyle="bullet"> pour une liste à puces. C'est en principe au layout à
mettre en page correctement la liste.
5. Pour la mise en évidence d'un texte ou d'une partie de texte, on utilise
TOUJOURS d'abord le style gras <Style Type="bold">.
On n'utilise par
conséquent presque jamais les styles italique <Style Type="italic"> ou
souligné <Style Type="underline"> dans les formulaires wallons ou les couleurs
<Style Type="red">.
Recommandation :
La mise en évidence d'un texte se fait en gras.
On ne multiplie pas les types de mise en évidence. Par exemple, le rouge n'est
pas recommandé :
1. Ce n’est pas dans la charte graphique des formulaires papier. Pas non plus
dans celle des formulaires web (couleurs de l’arc-en-ciel de la charte « Ensemble
simplifions »).
2. Le rouge en ergonomie doit être réservé aux erreurs, c’est important de
garder cette signification
3. Si on diversifie trop les moyens de mise en évidence, plus rien ne ressort du
lot.
→ en résumé : trop de mise en évidence tue la mise en évidence … et l’identité
graphique.
Page 75 sur 102
Juillet 2016
6. Utiliser le gras <Style Type="bold"> pour mettre en évidence le mot significatif
dans une liste à puce <List MarkerStyle="bullet"> ou une liste numérotée
<List MarkerStyle="number"> ou encore une série de <RadioBox>.
7. En cas de phrase orpheline (phrase qui se retrouve seule à la page suivante),
remplacer <Paragraph> par <Paragraph Spacing="x-small"> peut essayer de la
replacer sur la page précédente. ATTENTION !!! À n'utiliser que très rarement
et surtout en toute fin de fabrication, au moment du réglage final des sauts
de page pdf.
*****
Page 76 sur 102
Juillet 2016
Recommandation n° 23. Tableaux
23.1 PRINCIPES
Les tableaux peuvent servir dans 3 cas :
• le tableau réel de données avec une liste d'objets en vertical (ordonnée) et une
liste de caractéristiques en horizontal (abscisse)
• le tableau de mise en disposition (à éviter autant que possible),
• le tableau de choix multiples avec contenu dynamique.
Recommandation
Il faut garder le plus possible la structure xml du formulaire conforme à la
structure réelle des données.
Les tableaux ne peuvent pas servir à mettre en page dans les autres cas.
Par exemple, pour faire une liste, on utilise obligatoirement une liste numérotée <List
MarkerStyle="number"> ou une liste à puces <List MarkerStyle="bullet">. C'est en
principe au layout (et non au tableau !) à faire la mise en page correcte.
23.2 TABLEAU
RÉEL DE DONNÉES
Exemple : on a une liste de n objets (Isolants) et leur caractéristiques en tête de
colonne
Type d'isolant
Marque
Valeur λ
Épaisseur d Coefficient R
Isolant 1
Isolant 2
Isolant 3
Isolant 4
23.3 TABLEAU
DE MISE EN DISPOSITION
Pour gagner de la place et grouper les champs qui ont un sens sémantique commun
(ce qui est le cas, par exemple, pour la rue, le numéro, etc. dans l'adresse), au lieu de
placer les champs d'interrogation en enfilade, comme suit :
Rue
Numéro
Boîte
Page 77 sur 102
Juillet 2016
Code
postal
Localité
… on préférera les disposer plus groupés, comme suit :
Rue
Numéro
Code
postal
23.4 TABLEAU
Boîte
Localité
DE CHOIX MULTIPLE AVEC CONTENU DYNAMIQUE
Un radio bouton avec, par exemple 3 choix. Si on coche le premier, un cadre (filet
tableau="border") s'ouvre avec plusieurs questions (dans des <Paragraph> et des
<Table>) Si on coche un autre, le premier cadre se ferme, et le suivant s'ouvre...
Etc.
Question posée toto ou fifi ou ruru ? :
□
Toto
□
□
□
M.
Nom
Prénom
Mme
Fifi
Numéro d'entreprise
□
Ruru
Autre question
<Content>
<Paragraph>Question posée toto ou fifi ou ruru ?</Paragraph>
<Table StyleName="noBorder">
<ColumnDefinitions>
Page 78 sur 102
Juillet 2016
<TableBody>
<Tr>
<Td Colspan="2" Rowspan="1" VerticalAlignment="middle">
<Paragraph>
<Question>
<RadioBox Name="choix">
<Option Value="toto">Toto</Option>
</RadioBox>
</Question>
</Paragraph>
</Td>
</Tr>
<Tr IsVisible="$(choix)=='toto'">
<Td><Paragraph></Paragraph></Td>
<Td Colspan="2" Rowspan="1" StyleName="border">
<Paragraph>
<Question>
<Label>Question 1 si toto</Label>
<TextBox Name="choix1question1" />
</Question>
</Paragraph>
<Paragraph>
<Question>
<Label>Question 2 si toto</Label>
</Question>
</Paragraph>
<Table StyleName="noBorder" />
</Td>
</Tr>
<Tr IsVisible="$(choix)=='toto'">
</Tr>
<Tr>
<Td Colspan="2" Rowspan="1">
<Paragraph>
<Question>
<Option Value="fifi">Fifi</Option>
</RadioBox>
</Question>
</Paragraph>
</Td>
</Tr>
<Tr IsVisible="$(choix)=='fifi'">
<Paragraph>
<Question>
<Label>Question 1 si fifi</Label>
</Question>
</Paragraph>
<Paragraph>
<Question>
Page 79 sur 102
Juillet 2016
<Label>Question 2 si fifi</Label>
</Question>
</Paragraph>
</Td>
</Tr>
<Tr IsVisible="$(choix)=='fifi'">
</Tr>
<Tr>
<Td Colspan="2" Rowspan="1">
<Paragraph>
<Question>
<Option Value="ruru">Ruru</Option>
</RadioBox>
</Question>
</Paragraph>
</Td>
</Tr>
<Tr IsVisible="$(choix)=='ruru'">
<Paragraph>
<Question>
<Label>Question 1 si ruru</Label>
</Question>
</Paragraph>
</Td>
</Tr>
</TableBody>
</Table>
</Content>
23.5 LARGEUR
DES COLONNES
Ne jamais fixer la taille d'une cellule via <td width="50%">. Toujours utiliser les balises
<columnDefinitions> et <columnDefinition>.
Exemple :
<Paragraph>
<Table OutputMode="all" HorizontalAlignment="left">
<ColumnDefinitions>
<TableHeader>
<Tr>
<Th Colspan="1" Rowspan="1" VerticalAlignment="top">
<Paragraph OutputMode="all" HorizontalAlignment="left"
Spacing="normal">¤</Paragraph>
</Th>
Page 80 sur 102
Juillet 2016
</Th>
</Th>
</Tr>
</TableHeader>
<TableBody>
<Tr>
</Td>
</Td>
Spacing="normal">¤<Question><Label>Libellé question¤</Label><TextBox
Name="nom_variable" RefreshOnExit="false" DataType="string"
NumberOfVisibleCharacters="15" IsRequired="false" /></Question></Paragraph>
</Td>
</Tr>
</TableBody>
</Table>
23.6 LES
TABLEAUX ET
FOP
Quand on a un <Table> avec plusieurs <Tr> tous AVEC condition, si aucun des
conditions n'est true, alors on a un <Table> vide de <Tr>. Fop ne tolère pas ça lors
de transformation du fichier .fo en .pdf.
Ce problème est très difficile à détecter... Il faudrait dans l'idéal que Jway puisse faire
un test sur ça à la compilation, mais c'est très complexe...
Exemple :
<Table>
<ColumnDefinitions/>
<TableHeader/>
<TableBody>
<Tr IsVisible="($(item|actionnaire)=='physique')">
...
</Tr>
<Tr IsVisible="($(item|actionnaire)=='morale')">
...
</Tr>
</TableBody>
</Table>
Dans cet exemple, dès que la variable ne vaut ni "physique", ni "morale", on a un
problème de fabrication du fo2pdf... avec fop dynamique (donc bien après la
publication).
Le problème peut se poser également lorsqu'une cellule est vide. Il faut donc éviter le
cas de figure suivant :
Page 81 sur 102
Juillet 2016
<Table>
<ColumnDefinitions/>
<TableHeader/>
<TableBody>
<Tr IsVisible="($(item|actionnaire)=='physique')">
<Td>
<Paragraph IsVisible="($(a)=='toto')">
...
</Paragraph>
</Td>
</Tr>
</TableBody>
</Table>
Car si la variable a est différente de "toto", alors le <Td> sera vide.
Autrement dit, dans nos tests :
•
calcul du pdf vierge lors de la publication ---> bug indétectable car les
conditions sont annihilées
•
calcul du pdf lorsqu'on clique sur "Aperçu pdf" ---> bug indétectable car les
conditions sont annihilées
•
calcul du pdf lorsqu'on clique sur "Aperçu pdf" sur la dernière page du
formulaire (après "Valider") ---> bug détectable mais uniquement si les
variables se "mettent mal"... donc il faut tester avec des valeurs "idiotes" pour
espérer faire planter...
Recommandation
Le développeur de formulaire doit être très attentif en codant une table avec des
conditions sur les cellules <Td>.
Soit on évite absolument de mettre une condition sur toutes les lignes <Tr>
Soit il faut s'assurer que toutes les conditions couvrent l'ensemble des valeurs
possibles pour la variable de test dans la condition IsVisible.
Ne jamais placer de condition sur un <Paragraph> seul dans une cellule.
*****
Page 82 sur 102
Juillet 2016
Recommandation n° 24. Formattage des champs
24.1 TYPES
Integer – String – Double – Boolean
24.2 ARRONDIS
pour faire un arrondi d'une valeur
24.3 QUAND
UTILISER ASNUMBER
?
a=asNumber(zzzzz)
b=asNumber(gggg)
faut-il
c=a+b
ou
c=asnumber(a) + asnumber(b)
?
24.4 FORMAT
COMME ATTRIBUT
ATTENTION !!!
vérifer formattage format="####" ; exemple format="#.##", alors « 99,4 » devient
« 9.94 » dans un formulaire de FMO (formulaire Entreprise d'Insertion) Regarder la
doc sur University
24.5 FORMAT
DANS
JIL
dans une commande JIL, comment fait-on le formattage ?
*****
Page 83 sur 102
Juillet 2016
Recommandation n° 25. Libellés des questions
25.1 PRINCIPE
Recommandations
Toujours utiliser un <Label> pour le libellé d'un champ, dans une <Question>.
Ne jamais mettre « : » à la fin du libellé.
25.2 EXCEPTION
POUR L'UTILISATION DU
<LABEL>
Dans un tableau réel de données (cf. recommandation n° 23, page 77, pour la
définition d'un tableau réel de données), le label est le titre de la colonne (dans le
header, c'est-à-dire un label par cellule du header <TH>).
Par contre, dans un tableau de mise en disposition (cf. recommandation n° 23,
page 77, pour la définition d'un tableau de mise en disposition), il faut toujours
utiliser <Label>.
25.3 LABELS
TROP LONGS
Si le label est trop long :
1. raccourcir approximativement à la taille visuelle du champ (pas indispensable,
mais esthétique et c'est un travail de lisibilité nécessaire, car un libellé de
question trop long n'est pas lisible)
2. sauf si c'est un champ mémo (sauf qu'un libellé trop long est par définition
toujours à proscrire si pas lisible)
*****
Page 84 sur 102
Juillet 2016
Recommandation n° 26. Blocage de l'accès direct
26.1 PRINCIPE
Pour bénéficier des interactions avec le portail (pré-remplissage, sauvegarde, upload
d'annexes, soumission), il faut que l'usager aie une session avec le portail. Il faut
donc éviter qu'il aille directement sur le formulaire sur le serveur Tomcat des
formulaires.
Recommandation
Pour éviter que les usagers accèdent directement à un formulaire sans session, on
bloque l'accès en direct.
Ceci se fait pour tous les formulaires sauf exception explicite, dans la liste des
formulaires suivants :
Déclaration des mandats
exigence de la Cellule de déclaration des
mandats (M. Nicole MATAGNE)
26.2 TECHNIQUE
Le blocage de l'accès en direct sur le formulaire (et l'obligation pour l'usager de passer
par le site formulaires.wallonie.be) est matérialisé par 3 éléments indispensables :
•
l'adaptation paramétrée des templates dynamique dans le MY.REF et plus
particulièrement MYREF/dynamic_templates/form.xhtml, notamment via les
quelques lignes suivantes :
<?variable easi.form.direct=getProperty('easi.form.direct') ?>
<?if (($(easi.server.prod)=='YES') && ($(existPortal)=='false') && ($
(easi.form.direct)!='ENABLED')) ?>
<body>

<object classid="jway.applyxslt">
<param name="jway.xsl" value="ref/xslt/pubHTML/formHeader" />
</object>

<div class="container">
<object classid="jway.applyxslt">
<param name="jway.xsl" value="ref/xslt/pubHTML/contentSpecial" />
<param name="jway.resourceId" value="redirect.jxml$" />
</object>
</div>
</body>
•
la variable easi.server.prod (YES/NO) dans
.jway/jPublisherConfig.properties, variable liée donc au serveur
Page 85 sur 102
Juillet 2016
•
la variable easi.form.direct (ENABLED/DISABLED) dans APPLI.REF/
publication.properties de l'environnement du formulaire, variable liée donc au
formulaire
26.3 CAS
DE BLOCAGE
Il est clair que le blocage n'est utile que sur le serveur de production. Donc, le
paramètre easi.server.prod n'est positionné à YES que sur le serveur de production,
pas sur les autres.
serveurs
easi.serve blocage accès direct
r.prod
easi.form.direct=ENABL easi.form.direct=DISAB
ED
LED
forms6.test.wallonie.be
NO
NON
NON
forms6.wallonie.be
YES
NON
bloqué
*****
Page 86 sur 102
Juillet 2016
Recommandation n° 27. Accès DB en lecture
27.1 FICHIER
DE CONFIGURATION
Dans APPLI.REF/publication.properties
# -- MYSQL database local-#jway.remote.db.jdbcdriver=com.mysql.jdbc.Driver
#jway.remote.db.url=jdbc:mysql://localhost/test_db
#jway.remote.db.user=root
#jway.remote.db.password=***********
# -- ORACLE database de PRODUCTION (DEX) -#jway.remote.db.jdbcdriver=oracle.jdbc.driver.OracleDriver
#jway.remote.db.url=jdbc:oracle:thin:@157.164.138.97:1521:tora101
#jway.remote.db.user=FORMS
#jway.remote.db.password=**********
# -- ORACLE database de VALIDATION (DEX) -jway.remote.db.jdbcdriver=oracle.jdbc.driver.OracleDriver
jway.remote.db.url=jdbc:oracle:thin:@157.164.138.97:1521:tora101
jway.remote.db.user=FORMS
jway.remote.db.password=**********
27.2 EXEMPLE
DE
« PROCESSING INSTRUCTIONS »
DANS LE FORMULAIRE
L'appel dans le formulaire (exemple dans ce cas ci-dessous : médiation de dettes)
<Content>
<Paragraph OutputMode="interview">*** DEBUG : AVANT DB *** : demandeur|
num_agrementOld=<Data Expression="$(demandeur|num_agrementOld)" /></Paragraph>
<Paragraph OutputMode="interview">*** DEBUG *** : demandeur|num_agrement
=<Data Expression="$(demandeur|num_agrement)" /></Paragraph>

<?if-exist $(demandeur|num_agrement)?>
<?if $(demandeur|num_agrement) != null?>
<?if $(demandeur|num_agrement) != $(demandeur|num_agrementOld) ?>
<Variable Name="demandeur|num_agrementOld" Expression="$(demandeur|
num_agrement)" />
<?if $(DB_RequestDone) == null ?>
<Variable Name="args[0]" Expression=""request"" />
<?variable args[1]="SELECT * FROM institutions WHERE Agr='"+$(demandeur|
num_agrement)+"'"?>
<Variable Name="res"
Expression="JilExtension("lu.jway.util.jilextension.JdbcConnector",$
(args))" />
<Variable Name="DB_RequestDone" Expression="1" />
<?end-if?>
<?if (getSize($(res))==0)?>
<?setInterviewErrorOnField demandeur|num_agrement : "Numéro d'agrément non
valide."?>
<?end-if?>
<?if ( getSize($(res))==1 ) ?>
<Variable Name="demandeur|identification|denomination" Expression="$
(res[0]|denomination)" />
Page 87 sur 102
Juillet 2016
<Variable Name="demandeur|identification|institution|adresse|rue"
Expression="$(res[0]|adr_rue)" />
<Variable Name="demandeur|identification|institution|adresse|numero"
Expression="$(res[0]|adr_numero)" />
<Variable Name="demandeur|identification|institution|adresse|boite"
Expression="$(res[0]|adr_boite)" />
<Variable Name="demandeur|identification|institution|adresse|cp"
Expression="$(res[0]|adr_cp)" />
<Variable Name="demandeur|identification|institution|adresse|localite"
Expression="$(res[0]|adr_localite)" />
<Variable Name="demandeur|secteur" Expression="$(res[0]|secteur)" />
<Variable Name="demandeur|statutJuridique" Expression="$(res[0]|statut)" />
<Variable Name="demandeur|detailConventionCpas" Expression="$(res[0]|
convetion)" />
<?if $(demandeur|detailConventionCpas) == null ?>
<Variable Name="demandeur|conventionCpas" Expression=""NON"" />
<?else?>
<Variable Name="demandeur|conventionCpas" Expression=""OUI"" />
<?end-if?>
<?variable VarTemp = format ( '#######' , $(res[0]|population) ) ?>
<Variable Name="demandeur|population" Expression="asNumber( $
(VarTemp) )" />

<Variable Name="demandeur|smd|adresse|rue" Expression="$(res[0]|
smd_rue)" />
<Variable Name="demandeur|smd|adresse|numero" Expression="$(res[0]|
smd_numero)" />
<Variable Name="demandeur|smd|adresse|boite" Expression="$(res[0]|
smd_boite)" />
<Variable Name="demandeur|smd|adresse|cp" Expression="$(res[0]|smd_cp)" />
<Variable Name="demandeur|smd|adresse|localite" Expression="$(res[0]|
smd_localite)" />
<?variable VarTemp = format ( '####' , $(res[0]|agrement_annee) ) ?>
<Variable Name="demandeur|agrement|anneePremierAgrement"
Expression="asNumber( $(VarTemp) )" />

<?variable demandeur|agrement|dateDebut = afficheDate( getDate( $(res[0]|
agrement_debut) , "dd/MM/yyyy") , "dd/MM/yyyy") ?>
<?variable demandeur|agrement|dateFin
= afficheDate( getDate( $(res[0]|
agrement_fin) , "dd/MM/yyyy") , "dd/MM/yyyy") ?>
<Variable Name="demandeur|banque|numBancaireBE" Expression="$(res[0]|
compte_financier)" />

<Variable Name="demandeur|identification|denominationOrig" Expression="$
(demandeur|identification|denomination)" />
<Variable Name="demandeur|identification|institution|adresse|rueOrig"
Expression="$(demandeur|identification|institution|adresse|rue)" />
<Variable Name="demandeur|identification|institution|adresse|numeroOrig"
Expression="$(demandeur|identification|institution|adresse|numero)" />
<Variable Name="demandeur|identification|institution|adresse|boiteOrig"
Expression="$(demandeur|identification|institution|adresse|boite)" />
<Variable Name="demandeur|identification|institution|adresse|cpOrig"
Expression="$(demandeur|identification|institution|adresse|cp)" />
<Variable Name="demandeur|identification|institution|adresse|localiteOrig"
Expression="$(demandeur|identification|institution|adresse|localite)" />
<Variable Name="demandeur|banque|numBancaireBEOrig" Expression="$
(demandeur|banque|numBancaireBE)" />
<Variable Name="demandeur|conventionCpasOrig" Expression="$(demandeur|
conventionCpas)" />
Page 88 sur 102
Juillet 2016
<Variable Name="demandeur|detailConventionCpasOrig" Expression="$
(demandeur|detailConventionCpas)" />
<Variable Name="demandeur|populationOrig" Expression="$(demandeur|
population)" />
<Variable Name="demandeur|smd|adresse|rueOrig" Expression="$(demandeur|smd|
adresse|rue)" />
<Variable Name="demandeur|smd|adresse|numeroOrig" Expression="$(demandeur|
smd|adresse|numero)" />
<Variable Name="demandeur|smd|adresse|boiteOrig" Expression="$(demandeur|
smd|adresse|boite)" />
<Variable Name="demandeur|smd|adresse|cpOrig" Expression="$(demandeur|smd|
adresse|cp)" />
<Variable Name="demandeur|smd|adresse|localiteOrig" Expression="$
(demandeur|smd|adresse|localite)" />
<?end-if?>

<?else?>
<Paragraph OutputMode="interview">||| DEBUG *** $(demandeur|num_agrement) =
$(demandeur|num_agrementOld) ! ***</Paragraph>
<?end-if?>
<?else?>
<Paragraph OutputMode="interview">||| DEBUG *** $(demandeur|num_agrement) =
null ! ***</Paragraph>
<?end-if?>
<?else?>
<Paragraph OutputMode="interview">||| DEBUG *** $(demandeur|num_agrement)
n'existe pas ! ***</Paragraph>
<?end-if?>
<Paragraph OutputMode="interview">*** ERROR*** : ERROR=<Data Expression="$
(res[0])" /></Paragraph>
<Paragraph>
<Variable Name="demandeur|num_agrementOld" DataType="string"
Submit="true" Expression="$(demandeur|num_agrementOld)" />
</Paragraph>
</Content>
27.3 CLASSES
À AJOUTER
Fichiers à rajouter dans le APPLI.REF
APPLI.REF\jpublisher_extension\wstx_lgpl_3_2_1.jar
APPLI.REF\jpublisher_extension\stax_api_1_0_1.jar
APPLI.REF\jpublisher_extension\ojdbc14.jar
APPLI.REF\jpublisher_extension\ojdbc14\oracle\[...]
APPLI.REF\jpublisher_extension\lu\jway\util\DBConnector.java
APPLI.REF\jpublisher_extension\lu\jway\util\jilextension\JdbcConnector.java
*****
Page 89 sur 102
Juillet 2016
Recommandation n° 28. Utilisation des champs mémo
28.1 UTILISATION
GÉNÉRALE DU CHAMP MÉMOR
Le champs mémo ne permet pas à l'usager de rédiger un texte riche (gras, souligné,
puces, images, etc.) Ceci le bride dans son expression et lui empêche également de
faire facilement des copier-coller.
Pour toutes les parties purement textuelles, descriptives, des formulaires (données
collectées qui sont rarement intégrées et exploitées dans un back-office ; par ex. : un
rapport d’activités, un descriptif de fonction, une fiche projet, etc.), il est préférable de
recourir à un document annexe, type word formaté, dans lequel les usagers peuvent
recourir au copier-coller, utiliser une mise en page travaillée, éventuellement insérer
un schéma ou une image, etc.
Recommandation :
D'une manière générale, l'utilisation du champ mémo n'est pas recommandée. Il
faut toujours préférer proposer de joindre un fichier word, permettant de rédiger
en texte riche.
28.2 TAILLE
AFFICHÉE
Pour fixer les dimensions du champs mémo, on compte en nombre de lignes
(NumberOfVisibleRows) et de caractères par ligne (NumberOfVisibleCharacters). Dans
l'exemple ci-dessous, c'est 3×15.
<MemoBox Name="item|avantagesNature|descriptif" RefreshOnExit="false"
NumberOfVisibleRows="3" NumberOfVisibleCharacters="15" AutoSize="true"
IsRequired="false">
<Control ErrorType="error" Type="rangeChar">
<Parameter Name="min" />
<Parameter Name="max" Value="75" />
</Control>
</MemoBox>
La
taille
de
la
largeur
de
la
page
pdf
est
de
88
caractères
(NumberOfVisibleCharacters="88"). Pour limite la taille à 1 page ou 1/2 page ou 1/4
page, il faut également fixer le nombre de ligne à NumberOfVisibleRows="45" (1 page),
NumberOfVisibleRows="22" (1/2 page) ou NumberOfVisibleRows="11" (1/4 page).
Recommandation
Si on utilise les champs mémo malgré la première recommandation, toujours
essayer de limiter la taille des champs, et en particulier celle des champs mémo.
Utiliser le compteur de caractère OBLIGATOIREMENT dès lors qu'il y a une limite
sur la taille d'un champ mémo.
Page 90 sur 102
Juillet 2016
28.3 TAILLE
DE LA RÉPONSE DE L'USAGER
Pour limiter la réponse de l'usager (minimum et maximum) dans un champs mémo,
on compte en nombre de caractères. Dans l'exemple ci-dessous, c'est 10 caractères
minimum et 100 maximum. En dehors de ces limites, le champs sera mis en erreur.
<Question>
<Label IsTooltipOnly="false">Minimum 10, maximum 100</Label>
<MemoBox Name="field1" RefreshOnExit="false" NumberOfVisibleRows="4"
NumberOfVisibleCharacters="88" AutoSize="false" IsRequired="false">
<Control ErrorType="error" Type="rangeChar">
<Parameter Name="min" Value="10" />
</Control>
</MemoBox>
</Question>
28.4 COMPTEUR
DE CARACTÈRES
Pour informer l'usager de la limite maximum de sa dans un champs mémo, on utiliser
le type rangeCharWithCounter.
<Question>
<Label IsTooltipOnly="false">Minimum 10, maximum 100</Label>
<MemoBox Name="field1" RefreshOnExit="false" NumberOfVisibleRows="4"
NumberOfVisibleCharacters="88" AutoSize="false" IsRequired="false">
<Control ErrorType="error" Type="rangeCharWithCounter">
<Parameter Name="min" Value="10" />
</Control>
</MemoBox>
</Question>
*****
Page 91 sur 102
Juillet 2016
Recommandation n° 29. Recalcul des totaux
29.1 PRINCIPE
Le rafraîchissement d'une page se fait en passant à une autre page. Ceci peut être
gênant pour l'usager lorsqu'il y a un calcul sur les valeurs que l'usager a déjà encodé
sur cette page et que le résultat de ce calcul doit apparaître sur cette même page.
Par exemple, le calcul de la somme des valeurs d'un tableau.
Recommandation :
Lorsqu'il y beaucoup de données sur une page, avec un calcul sur ces données, il
faut ajouter un petit bouton pour que l'usager puisse « Cliquer pour recalculer
les totaux ».
29.2 CODE
EXEMPLE
<Content OutputMode="interview" NewPage="none" StyleName="remarque">
<Paragraph OutputMode="all" HorizontalAlignment="left" Spacing="normal">
<Question>
<Label IsTooltipOnly="false">Cliquez ici pour recalculer les totaux
<Variable Name="afficherTotaux" Expression="'non'" Submit="false"
DataType="string" /></Label>
<CheckBox Name="afficherTotaux" RefreshOnExit="true" DataType="string"
ValueWhenChecked="oui" ValueWhenUnchecked="non" />
</Question>
</Paragraph>
</Content>
L'élément important est le RefreshOnExit="true".
*****
Page 92 sur 102
Juillet 2016
Recommandation n° 30. Liste de paires codes libellés
30.1 PRINCIPE
Recommandation :
On utilise cette technique lorsque l'usager doit pouvoir faire une recherche sur
base d'une paire codes-libellés, c'est-à-dire rechercher un libellé sur base d'un
code ou l'inverse, et lorsque cette liste de paires codes-libellés est peu
variable dans le temps, c'est-à-dire pas de modification plus fréquentes que les
mises à jour du formulaire correspondant.
30.2 PAR
DÉFAUT
Le fichier ./MY.REF/javascript/assistant_codelib.js contient 4 tables statiques (par
opposition à un accès à une table dynamique, dans une base de données par
exemple).
matrice
rang [x][0]
rang [x][1]
nombre
d'éléments
T[][]
code postal
commune
nb=2901
T1[][]
1 … 10
un … dix (pas le zéro !) nb1=10
T2[][]
code INS
commune
nb2=262
T3[][]
code NACE
libellé
nb3=1925
30.3 FICHIER
À MODIFIER POUR AJOUTER UNE LISTE NOUVELLE
Pour ajouter une nouvelle liste (T4 dans l'exemple ici), il faut modifier le fichier
suivant :
./APPLI.REF/javascript/assistant_codelib.js
et y ajouter les lignes suivantes pour former la nouvelle table de codes (colonne 0) et
libellés (colonne 1):
var nb4 = 500;
var T4 = new Array(nb4);
for(var cpt=0;cpt<nb4;cpt++)
T4[cpt] = new Array(2);
//--- remplissage
T4[0][0] = "010101"; T4[0][1] = "D\u00e9chets";
T4[1][0] = "010304"; T4[1][1] = "St\u00e9riles acidog\u00e8nes";
T4[2][0] = "010305"; T4[2][1] = "Autres st\u00e9riles";
T4[3][0] = "010307"; T4[3][1] = "Autres d\u00e9chets";
[...]
T4[498][0] = "140728"; T4[498][1] = "Autres filtres";
Page 93 sur 102
Juillet 2016
T4[499][0] = "140727";
T4[499][1] = "Filtres \u00e0 huile";
Attention ! Les caractères accentués doivent être codés selon
http://alis.isoc.org/codage/iso10646/rang_00.htm
remplacer également dans le même fichier, tout à la fin :
return T1;
par
if (format.substr(0,4) == "codespecial")
{
return T4;
}
else
{
return T1;
}
Dans le formulaire appelant, il faut
<Paragraph>
<Question class="String" required="yes" select="code">
<txt control="controlCode" format="codespecial" group="groupcodespecial"
size="10" type="assist"></txt>
</Question>
</Paragraph>
<Paragraph>
<Question class="String" select="agrement|dechets|dangereux|codes[$(k)]|
libelle">
<txt control="controlLib" format="codespecial" group="groupcodespecial"
size="40" type="assist"></txt>
</Question>
</Paragraph>
*****
Page 94 sur 102
Juillet 2016
Recommandation n° 31. Itérations
Recommandation :
Utiliser le DataIterator sur l'objet à multiplier.
31.1 EXEMPLE
DE CODE D'UN TABLEAU ITÉRATIF
<Table OutputMode="all" HorizontalAlignment="left" StyleName="sansBordures">
<ColumnDefinitions>
<ColumnDefinition Width="5%" WidthPaper="5%" />
<TableHeader>
<Tr>
<Paragraph OutputMode="all" HorizontalAlignment="center"
Spacing="normal">N°</Paragraph>
</Th>
<Paragraph OutputMode="all" HorizontalAlignment="center"
Spacing="normal">Dénomination de la filiale</Paragraph>
</Th>
</Th>
</Tr>
</TableHeader>
<TableBody>
<DataIterator InternalName="filiale" DataPath="filiales"
MinItemToPrint="3" />
<Tr>
<Td Colspan="1" Rowspan="1" VerticalAlignment="top">
<Paragraph OutputMode="all" HorizontalAlignment="center" Spacing="normal">
<Question>
<TextBox Name="filiale|numero" RefreshOnExit="false" DataType="string"
NumberOfVisibleCharacters="2" IsRequired="true" AutoSize="false">
<Control ErrorType="error" Type="default" />
</TextBox>
</Question>
</Paragraph>
</Td>
<Paragraph OutputMode="all" HorizontalAlignment="center" Spacing="normal">
<Question>
<TextBox Name="filiale|identification|denomination" RefreshOnExit="false"
DataType="string" NumberOfVisibleCharacters="82" IsRequired="true"
AutoSize="false">
<Control ErrorType="error" Type="default" />
</TextBox>
</Question>
</Paragraph>
Page 95 sur 102
Juillet 2016
</Td>
<IteratorControlButton Type="insertBefore" />
<IteratorControlButton Type="delete" />
<IteratorControlButton Type="insertAfter" />
</Td>
</Tr>
</TableBody>
</Table>
31.2 COMMENTAIRES
Tout ce qui est placé après le dataIterator sera dupliqué lorsque l'utilisateur cliquera
sur le bouton « + » et sera supprimé lorsque l'utilisateur cliquera sur le bouton « - ».
Les boutons n'apparaitront que pour la partie web (10%) et non pour la partie papier
(0%).
Valeurs pour fixer le nombre maximum et minimum d'éléments :
minItemToPrint
en pdf vierge
nombre de lignes affichées (ici 3)
en pdf rempli
nombre de lignes affichées (ici 3)
en web
ne sert pas car on affiche toujours 1 ligne minimum
*****
Page 96 sur 102
Juillet 2016
Recommandation n° 32. Ensemble de questions
FormPublisher permet de regrouper des <Question> dans un ensemble
<QuestionSet>. Cependant, la charte graphique eWBS ne le prévoit pas, et donc les
templates correspondants n'ont pas été définis, ni en html, ni en pdf.
Recommandation :
Ne pas utiliser l'objet <QuestionSet>.
*****
Page 97 sur 102
Juillet 2016
Recommandation n° 33. Notifications multiples
Recommandation :
Utiliser le code approprié pour la notification courriels multiples.
Lors de la soumission d'un formulaire à un compte GE, et éventuellement à une
application métier, un courriel de notification est envoyé à l'adresse courriel liée au
compte GE. Cette adresse courriel est fixe pour un formulaire et est précisée dans la
DB.
Par contre, il est possible de rajouter 0..N adresses courriels auxquelles le système
envoie le même courriel en BCC. Ces adresses sont précisées dans le datastore. où
les données xml doivent avoir la structure suivante :
<SYST_agents>
<item><email class="String">[email protected]</email></item>
</SYST_agents>
Il peut s'agir :
• soit de un ou plusieurs champs libres (en nombre fixé, ici par exemple 2) que
l'usager remplit lui-même. Attention ! Il y a un contrôle sur le champs courriel,
mais si l'usager encode une adresse valide avec une erreur, le courriel n'arrivera
pas, et il ne le saura pas.
<Paragraph>
<Question>
<Label>Destinataire notification premier courriel</Label>
<TextBox Name="SYST_agents[0]|email" DefaultValue="[email protected]" />
</Question>
<Question>
<Label>Destinataire notification second courriel</Label>
<TextBox Name="SYST_agents[1]|email" />
</Question>
</Paragraph>
•
soit de une ou plusieurs adresses fixes (en nombre fixé également, ici par
exempel 3) précisées sous forme de « variable » NB : pour être reprises dans le
datastore, il faut positionner l'attribut « Submit » à « True » :
<Variable Name="SYST_agents[0]|email" Expression="[email protected]"
Submit="True" DataType="string" />
•
Soit d'un nombre variable de champs libres :
<TableBody>
<DataIterator InternalName="item" DataPath="SYST_agents" />
<Tr>
Page 98 sur 102
Juillet 2016
<Paragraph>
<Question>
<Label>Destinataire notification courriel</Label>
<TextBox Name="item|email" />
</Question>
</Paragraph>
</Td>
<Td>
<Paragraph>
<IteratorControlButton Type="insertBefore" />
<IteratorControlButton Type="delete" />
<IteratorControlButton Type="insertAfter" />
</Paragraph>
</Td>
</Tr>
</TableBody>
*****
Page 99 sur 102
Juillet 2016
Recommandation n° 34. Problèmes de session
Tous les problèmes de session semblent avoir trouvé une solution avec la mise en
place de la page « ecola », en FormPublisher 3.0 :
• perte de session formulaire si l'usager reste sur la même page du formulaire
pendant plus de 30 minutes
• perte de session portail si l'usager utilise son formulaire plus de 30 minutes
sans sauvegarder ou soumettre
• session invalidée si double clic sur le bouton « Enregistrer »
• session permettant l'ouverture de 2 formulaires, avec conflit.
Néanmoins, malgré cette solution, il n'est pas inutile de recommander aux rédacteurs
de limiter la taille des pages du formulaire.
Recommandation :
Pages de longueur raisonnable dans les formulaires
Ne pas fabriquer une page avec trop long tableau ou trop de champs mémo.
Le cas échéant, toujours essayer de les subdiviser.
Si on fabrique un formulaire web avec une page très longue à remplir, ça prendra
forcément plus de 30 minutes à l'usager... même s'il ne baille pas aux corneilles.
Exemple édifiant : le formulaire d'accompagnement des chômeurs, v01.02.01 :
http://forms6.test.wallonie.be/FOREM_AccompagnementChomeurs_v01.02.01/formul
aire.html, cf. page « Objectifs et moyens prévus » : cette page contient 8 champs
mémo de 2800 caractères. Si l'usager ne fait pas des copier-coller, ça lui prendra pas
mal de temps pour taper 22 400 caractères.
Il faudrait donc que nous puissions imposer de subdiviser ce genre de page. Dans cet
l'exemple du Forem, il conviendrait de couper la page de 8 champs mémo en 8 pages
avec un seul champ chacune.
C'est à retenir dans les bonnes pratiques, lors du découpage du formulaire en sections
et sous-sections.
*****
Page 100 sur 102
Juillet 2016
Recommandation n° 35. Calcul du pdf avec FOP
FormPublisher fait appel à FOP pour calculer le pdf.
manières, en mode client ou en mode serveur.
Son paramétrage se fait comme suit.
FOP peut être appelé de deux
Recommandation
Il faut utiliser le mode serveur de FOP.
35.1 EN FORMPUBLISHER 3.1
ET PLUS ANCIEN
Dans MY.REF\common\publication.properties, il faut poser :
jway.param.pdfMode=server
Attention, il faut bien écrire « pdfMode » et non « pdfmode »
Vérifier que les paramètres
jway.param.pdfMode
et
jway.transformer.fopass.transport
ne sont pas dans les autres publication.properties (APPLI.REF, MY.REF, , common,
desktop, mobile)
Sur le serveur, dans .jway/formPublisherConfig.properties, il faut poser :
Pour activer la génération en mode serveur, il faut poser les 3 paramètres suivants :
jway.transformer.fopass.transport=http://fop1.wallonie.be/jwayServicesHub/pdfSe
rver
jway.transformer.fopass.mimetype= application/octet-stream
jway.transformer.fopass.ext=pdf
Pour activer la génération en mode ligne de commande (commenter la ligne, ne pas la
laisser vide) :
#jway.transformer.fopass.transport=http://fop1.wallonie.be/jwayServicesHub/pdfS
erver
jway.transformer.fopass.mimetype= application/octet-stream
jway.transformer.fopass.ext=pdfMY.REF/
35.2 EN FORMPUBLISHER 3.3
ET APRÈS
Il faut supprimer
jway.param.pdfMode=server
du MY.REF\common\publication.properties, et le poser dans
.jway/formPublisherConfig.properties.
De la sorte, l'e-form fabriqué en FP3.1 avec le paramètre de mode sera figé dans le
mode choisi jusqu'à republication. Tandis que l'e-form fabriqué en FP3.3 utilisera le
paramètre du serveur qu'on peut modifier si besoin.
Page 101 sur 102
Juillet 2016
Si on veut imposer le mode client, il suffit de poser (par convention) :
jway.param.pdfMode=local
dans .jway/formPublisherConfig.properties.
35.3 POINTS D'ATTENTION
•
•
•
Si les 3 paramètres sont absents, la génération repasse en mode ligne de
commande.
Si le serveur fop est indisponible, apache renvoie un code 503 (Service
Unavailable) et
◦ en FormPublisher 3.1 et plus ancien : l'e-form renvoie un fichier nommé
« .pdf » qui est en réalité le fichier .fo correspondant ; il faut renommer le
.pdf en .fo et lui appliquer fop fichier.fo fichier.pdf pour connaître les
messages d'erreur ;
◦ en FormPublisher 3.3 et après : fop en mode client est utilsé.
Idem si apache est indisponible, l'e-form s'en rend compte presque
instantanément.
35.4 NOTES
EN BAS DE PAGE
Il faut à tout prix éviter le recours aux notes en bas de page lors de la conception des
formulaires !
Recommandation
Jusqu’à nouvel avis : remplacer les notes en bas de page par un glossaire.
Si l’on peut comprendre le souci de l’administration d’apporter une aide aux usagers
au travers des notes en bas de page, force est de constater que ces notes provoquent
des problèmes répétés pour la construction des PDF dynamiques (= le PDF édité au
départ d’un formulaire complété en ligne). En effet, elles sont prévues pour apparaître
sur une page précise du formulaire et sont incompressibles. Dans les formulaires où
l’usager peut compléter des champs en texte libre, on ne peut, le plus souvent,
contrôler le nombre de lignes maximum qu’il y aura par page. Il peut venir un
moment où la taille du texte saisi par l’usager entre en conflit avec ces notes dont
l’encombrement sur la page est figé. Résultat : le PDF ne peut être généré !
Dans le formulaire électronique, il est possible de remplacer la fonctionnalité des
notes en bas de page par d’autres aides : glossaire, FAQ, … Les notes en bas de page
sont essentiellement utiles à l’usager qui complète son formulaire au format papier.
Elles pourraient donc être prévues pour la conception du PDF statique (= le PDF
vierge, qui comporte toutes les questions et est mis en page pour être « propre » en
présentation papier). Mais nous tendons à supprimer autant que possible ce PDF
statique. Autant dès lors éviter les notes en bas de page.
Le remplacement de FOP1.0 par FOP2.1 est une très sérieuse piste de solution.
*****
Page 102 sur 102

Fabrication de formulaires Cahier de recommandations

Transcription

Documents pareils

module de formation word formulaires et modèles

FORMULAIRE DE DEMANDE D`ANIMATION Nom

Continuing Education - Architects` Association of New Brunswick

acrobat initiation

formulaires maison : établissements d `accueil

Schéma simplifié du parcours des formulaires conventionnels

[IMAGE] Course Name: Solutions aux problÃ¨mes courants en matiÃ

formulaire de demande d`octroi de la carte d`identite professionnelle

FORMULAIRE OFFRE D`EMPLOI Type d`emplois : o Saisonnier o