[SharePoint 2010] Personnalisation de formulaires (partie 2) : modèle de formulaire

Dans le post précédent, on a vu comment modifier des formulaires en JavaScript et en XSL.

Dans ce post, nous allons voir la méthode que je préfère (hors InfoPath) quand il s'agit de créer un formulaire custom réutilisables.

La technique a été abordée dans un article MSDN de 2008 (http://msdn.microsoft.com/en-us/library/aa544142.aspx) mais reste valable pour MSS 2010.

Une très grande partie du rendu de SharePoint dépend de « modèles ». Ces modèles sont définis dans le fichier DefaultTemplates.ascx situé dans 14\TEMPLATE\CONTROLTEMPLATES.

En l'inspectant avec Visual Studio (plus pratique que Notepad grâce à la coloration syntaxique), on voit qu'il n'y a que des SharePoint :RenderingTemplate.

Pour rendre un formulaire unifié pour chaque liste, ListFormWebPart se base sur le modèle de formulaire défini dans le type de contenu qu'elle doit rendre.

Si on prend la définition du type de contenu racine, « Elément », on voit qu'il référence le modèle de formulaire « ListForm ».

Pour avoir un modèle personnalisé, une bonne pratique consiste à créer un type de contenu et référencer de la même manière un modèle de notre conception. Ci-dessous, on voit un type de contenu personnalisé, qui hérite de « Elément », référence 3 colonnes et surtout, défini un document XML indiquant à SharePoint qu'il devra utiliser un modèle nommé « DemandesListForm » pour rendre les formulaires de création, modification et affichage.

Pour créer un nouveau modèle, on doit créer un fichier ASCX dans le dossier CONTROLTEMPLATES reprenant les mêmes déclarations que DefaultTemplates, copier-coller le template « ListForm » et le renommer en DemandesListForm.

Maintenant qu'on a notre modèle, on peut à notre gré changer le DOM, utiliser les contrôles SharePoint, ASP.NET ou même nos propres contrôles.

Dans la capture ci-dessous, j'ai remis le JavaScript utilisé dans le post précédent et j'ai aussi mis le champ « Demandeur » en face du champ « Titre ».

Attardons-nous sur certains de ces contrôles :

  • ListFieldIterator est le champ qui va générer tous les contrôles HTML dans une table. Il a lui-même un template qui utilise pour chaque ligne de la table un contrôle CompositeField. Ce contrôle a également un template qui va utiliser FormField, FieldDescription et AppendOnlyHistory.

    Un des avantages de ListFieldIterator est qu'il ne va générer que les champs qui n'ont pas déjà été générés dans le formulaire. Ainsi, je place toujours ce contrôle à la fin de mes formulaires personnalisés pour permettre à mes utilisateurs de rajouter des champs manuellement une fois que la solution aura été déployée.

  • FormField est le contrôle qui va rendre le contrôle HTML lié à un champ. On passe simplement en paramètre le nom interne du champ dans l'attribut FieldName (c'est ce que fait CompositeField et ListFieldIterator quand on les laisse faire).
  • FieldDescription fonctionne exactement comme FormField et affiche le libellé du champ.
  • AppendOnlyHistory est utilisé par les champs de type Texte enrichi. Il s'agit d'une option permettant de n'enregistrer que le différentiel quand on modifie la valeur d'un champ qui aurait été paramétré pour.

Point important à noter : quand on référence manuellement des champs, on aura un plantage (Internal Server Error 500) si on se trompe de nom interne ou si le champ n'existe pas ! Il faut donc être prudent si les utilisateurs finaux ont la possibilité de modifier les listes.

Enfin, nous allons déployer tous ces éléments avec un WSP. Le package comportera un module pour provisionner le JavaScript, des définitions de Type de contenu et de colonnes et un dossier mappé pour déployer notre ASCX.

Maintenant, quand un utilisateur voudra créer, modifier ou afficher un élément utilisant notre type de contenu, il aura l'interface suivante :

Les principaux avantages de ce type de personnalisation sont qu'il s'agit uniquement d'ASP.NET, on peut donc développer comme on le souhaite, et que c'est lié aux types de contenu, ce qui permet une très grande flexibilité et réutilisabilité.

Le principal inconvénient est que c'est du développement donc, ce n'est pas à la portée d'un utilisateur final et il faut déployer un WSP en mode Farm.

Vous retrouverez les sources de cet exemple ici:

Dans le dernier post, nous verrons comment utiliser InfoPath 2010.

Publié dimanche 16 janvier 2011 19:57 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