[SharePoint 2010] Personnalisation de formulaires (partie 3) : InfoPath

Dans les précédents posts, nous avons vu comment modifier des formulaires avec du JavaScript, avec SharePoint Designer et avec des modèles ASP.NET. Dans ce post, je vais vous présenter les deux modes de formulaires que le logiciel InfoPath 2010 permet de créer pour SharePoint.

InfoPath est apparu en 2003 dans la suite Office. A l'époque, il ne permettait qu'une intégration très limitée avec SPS 2003. Dans sa version 2007, l'intégration était plus poussée avec, notamment, la possibilité de remplir des formulaires en mode Web, directement dans SharePoint (édition entreprise uniquement). La version 2010 propose à son tour son lot de fonctions supplémentaires et devient maintenant partie intégrante de SharePoint (elle est notamment utilisée par SharePoint Workspace pour fournir l'interface de saisie d'une liste synchronisée hors ligne).

Personnalisation de liste

Une des fonctions les plus intéressantes de cette version 2010 est la possibilité de personnaliser des formulaires de liste. Une icône est présente dans le ruban pour ouvrir directement InfoPath en modification sur le formulaire de la liste courante (on peut également le faire depuis SharePoint Designer).

Cliquer sur ce bouton ouvre InfoPath et génére automatiquement une source de données liée aux champs de la liste ainsi qu'une vue avec tous les champs en tableau.

On peut ensuite modifier le formulaire grâce au designer, rajouter des règles de validation sur des champs, du formatage, des images…

Pour appliquer ces modifications, on clique sur Quick Publish ce qui télécharge le formulaire dans SharePoint et l'associe à la liste.

Quand on édite un élément, on a maintenant notre nouvelle interface.

Les avantages de cette méthode sont le côté user-friendly et à la portée des utilisateurs à l'aise avec Office. Les règles de validation sont souples et peuvent prendre en compte des regex.

Les inconvénients viennent du fait qu'on est limité aux outils du designer InfoPath (pas de code client ni serveur), et que le modèle de données est limité aux colonnes de la liste De plus, ce mode de personnalisation repose sur la liste et pas le type de contenu.

Bibliothèque de formulaires

Les formulaires InfoPath basés sur une bibliothèque de formulaires proviennent d'InfoPath 2003.

Pour les créer, on ouvre InfoPath et on choisit le modèle SharePoint Form Library.

On note qu'InfoPath nous propose plus d'options que lors d'une personnalisation de liste.

On dispose d'un onglet « Developer » ainsi que de contrôles supplémentaires. La principale différence de ces derniers est que ce modèle de formulaire supporte une source de données hiérarchique et non tabulaire comme les listes classiques. Ainsi, on peut créer des listes à puce, des choix multiples…

Ces contrôles particuliers définissent des nœuds « Groupe » dans la source de données :

Je me sers également de cette possibilité quand je veux organiser ma source de données pour grouper des champs (imaginez un formulaire avec un groupe de champs « Général », « RH » et « DSI »).

Code serveur

Le plus gros avantage lorsque l'on travaille sur des formulaires InfoPath pour SharePoint, c'est la possibilité d'y insérer du code .NET. L'onglet Developer nous permet de rajouter du code à notre formulaire (disponible uniquement si la « programmabilité .NET » a été cochée à l'installation d'InfoPath).

Code Editor ouvre une sorte de de Visual Studio 2005 light appelé VSTA. On aura la possibilité de modifier certains aspects du formulaire lors de son chargement, d'intéragir sur certains événements, et effectuer une validation personnalisée. Ce sujet méritant plus qu'un simple paragraphe, il sera couvert en détails lors du prochain post.

Vues

Contrairement à la personnalisation de liste, ce modèle nous permet de créer autant de vues que l'on souhaite :

Ceci, combiné à un événement lors du chargement du formulaire, peut nous permettre de n'afficher à l'utilisateur que ce qu'il a le droit de voir.

Promotion des champs

Dans ce modèle, nous sommes entièrement libres dans notre source de données, on peut choisir quels champs seront « promus » comme colonnes de liste.

Dans les options du formulaire, on sélectionne les champs à promouvoir.

On donne le nom qui sera utilisé pour la colonne de liste.

Les principaux avantages de ce modèle :

  • On peut presque tout faire. Les power users peuvent utiliser le logiciel et créer leur propre formulaire, les concevoir puis les donner aux développeurs qui rajouteront la logique métier.
  • Ce modèle supportant les types de contenu, il est réutilisable facilement.
  • Le déploiement supporte les Sandbox.
  • Modèle de données extensible (XML)

Les inconvénients :

  • On est limité au framework InfoPath. La couche graphique est très peu (ou très difficilement) personnalisable.
  • Code limité au Framework .NET 2.0
  • Développement dans VSTA et non dans Visual Studio 2010
  • L'utilisation de code impose une approbation de l'administrateur de la ferme, ou un déploiement en mode sandbox si disponible.

Récapitulatif des principales différences

Formulaires basés sur des documents

Formulaires de listes

Source de données gérée dans le document (promotion facultative de champs)

Source de données gérée par SharePoint

Modèle de données hiérarchique (XML)

Modèle de données tabulaire

Possibilité de code-behind

Pas de code-behind

Problématique de génération des noms des documents

Limitations liées au schéma de données

Identifiant unique basé sur un nom de fichier (.xml)

Identifiant unique incrémental

Promotion de champ sélective

Tous les champs sont des colonnes de liste

 

Ces solutions nécessitent InfoPath 2010 (Office Pro Plus ou séparément) et une licence SharePoint Server Entreprise. Malgré son coût, elle permet de gagner beaucoup de temps lorsque l'on doit créer des formulaires complexes, réutilisables et faciles à maintenir.

J'espère que ce tour d'horizon des différentes méthodes de personnalisation des formulaires SharePoint pourra vous être utile !

Publié dimanche 16 janvier 2011 22:14 par Pierrick CATRO-BROUILLET
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :

Commentaires


Les 10 derniers blogs postés

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01