Développement

InfoPath (2003) supporte deux types de langages: le VBScript et le JScript (la version 2007 support le C# en plus et la 2010 ne support plus que du VB.Net ou du C#.Net). Un formulaire spécifique ne peut utiliser qu’un de ces deux langages et vous devez sélectionner le langage avant d’activer l’affichage du client de scripting.
Pour ce faire, allez dans Tools/Form Options et dans l’onglet Advanced pour InfoPath 2003 (sinon dans 2007 c’est dans Tools/Form Options et dans la section Programming et dans 2010 dans File/Info/Form Options):
Pour éditer du code dans InfoPath la méthode la plus rapide consiste à faire la combinaison de touches Alt+Shift+F11. Après il apparaît à l’écran..

Remarque: Il est important de se souvenir que le langage JScript est sensitif à la casse.
Il peut être utile dans un formulaire d’avoir la date de création insérée automatiquement dans un champ. InfoPath a déjà une fonction intégrée pour cela mais faisons le en code pour le fun…
Créez ainsi un formulaire vierge et insérez y un contrôle (champ) de type texte que vous nommerez date. Après dans le menu Tools choisissez Script/On Load Event. Insérez-y le code suivant (pour InfoPath 2003 seulement car depuis 2007 cela a complètement changé):

function XDocument::OnLoad(eventObj) { var dateField = XDocument.DOM.selectSingleNode(« //my:date »); dateField.text = todaysDate(); } function todaysDate() { var d = new Date(); var s = (d.getMonth() + 1) + « / »; s += d.getDate() + « / »; s += d.getFullYear; return(s); }

Remarquez l’expression XPath //my:date pour identifier l’élément que nous souhaitons manipuler et la fonction Javascript connu pour formater un date au format voulu (très connue par les webdesigners).L’autre considération à prendre en compte est simplement lorsque le formulaire sera sauvé et ouvert à nouveau. Effectivement, la plupart des personnes souhaitent que la date reflète celle de création du document. A ce moment là, il va falloir adapter un peu le code pour qu’il ne mette pas à jour le champ date lorsque une date s’y trouve déjà. On changera alors la procédure en ajoutant à l’endroit ad hoc:

if (dateField.text = = «  ») dateField.text = todaysDate();

Remarque: par ailleurs ne pas ajouter cette ligne peut créer des surprises lorsque l’on ouvre un formulaire déjà existant.
Exercice: À l’aide de ce qui a été vu, créez une petite calculatrice qui fait l’addition de deux champs.

Dangers

Il est extrêmement rare que je parle des dangers d’un produit. Au même titre que pour MS Office SharePoint (voir mon livre électronique sur le sujet) où il est extrêmement dangereux de le déployer dans une entreprise sans un architecte et un spécialiste de la gouvernance SharePoint, InfoPath a un piège très dangereux qui est le suivant:
Si vous modifiez un modèle de formulaire de façon conséquente (perso je dirai même si vous le faites de manière minime…), n’écrasez jamais l’ancien modèle car il se peu dès lors en fonction des modifications que vous avez faites que plus aucun des formulaires remplis avant le changement ne puissent s’ouvrir dans le nouveau modèle!!!! Il vaut donc mieux garder les anciens modèles pour retraiter les anciennes saisies et publier à côté la nouvelle version. Ainsi, vous pourrez nommer et publier vos modèles respectivement sous le nom:
– NotesDeFraisV1_0r8 – NotesDeFraisV2_0r17 – etc.
Malheureusement, même si cette astuce est facile à mettre en place avec InfoPath utilisé sur des disques réseaux, il en va tout autrement lorsque vous utiliser InfoPath Services. Cette dernière configuration et l’erreur qui s’en suivra (et les centaines d’heures de correction) vous apprendra pourquoi avant de créer un formulaire on passe plusieurs jours à le modéliser (analyse fonctionnelle et structurelle).

InfoPath vs Webforms

Bien que InfoPath soit infiniment plus puissant que MS Word pour faire des formulaires, il n’en reste pas moins à ce jour un outil bureautique s’adressant principalement à des non informaticiens qui ne souhaitent ou ne savent pas faire du code et qui sont donc limités par rapport à leurs besoins réels.
Voici les points les plus demandés par des utilisateurs que l’on ne peut faire que via de la programmation informatique pure et pour lesquels il devient dès lors plus avantageux de laisser tomber InfoPath en ce qui concerne les formulaires Internet:
1. Limitations des contrôles non compatibles sur le navigateur (InfoPath Services)
2. Impossible de créer sur le navigateur des contrôles de son choix (limités aux contrôles proposés par Microsoft).
3. Cryptage des données sur le canal non possible
4. Gestion des cookies ou des variables de session non possible
5. L’accès à un formulaire sans avoir accès à la liste SharePoint n’est pas possible (problème avec l’accès anonyme donc).
6. Pas possible de faire des formulaires structurés en plusieurs étapes (du type assistant avec des boutons Suivant) qui se passent des paramètres.
7. Pas possible de centraliser le design et les fonctionnalités (mise à jour en cascade)
8. Ne marche bien que dans un environnement Microsoft avec des utilisateurs ayant un compte Active Directory et InfoPath Designer ou InfoPath Filler installé sur leur poste.
9. La mise à jour de la structure d’un formulaire avec SharePoint 2007 est cauchemardesque
10. Impossible de faire des éléments graphiques (diagrammes du type Excel) ou formules dynamiques complexes (genre formule de Black & Sholes) en fonction de la saisie en temps réel.
11. Il n’est pas possible de gérer les écritures concurrentes dans une base de données.