Procédure : créer un type de champ personnalisé

Article
09/24/2014

Dernière modification : jeudi 3 mars 2011

S’applique à : SharePoint Foundation 2010

Dans cet article
1. Créer une définition de type de champ
2. Créer une classe de champ
3. (Facultatif) Créer une feuille de style XSLT personnalisée
4. Créer une classe de contrôle de rendu
5. Créer un ou plusieurs modèles de rendu
6. (Facultatif) Créer un type de valeur de champ
7. (Facultatif) Créer un contrôle d’édition
8. Déployer les éléments
Différence entre le rendu des champs pour les périphériques mobiles et le rendu des champs pour les ordinateurs

Cette rubrique fournit une vue d’ensemble du processus de création d’un type de champ personnalisé et de définition de son rendu sur les affichages de liste et sur les formulaires Affichage, Nouveau et Modifier.

Pour un exemple concret de création d’un champ personnalisé et de définition de son rendu, voir Procédure pas à pas : création d'un type de champ personnalisé.

1. Créer une définition de type de champ

Une définition de type de champ est un fichier XML qui contient les informations dont a besoin Microsoft SharePoint Foundation pour inscrire le type de champ et restituer le champ correctement. Ce fichier comporte notamment des informations sur l’assembly qui comprend le type de champ compilé.

Pour plus d’informations sur les définitions de type de champ, voir Procédure : créer une définition de type de champ personnalisé.

2. Créer une classe de champ

Une classe de champ est une classe dont les instances peuvent représenter des champs particuliers basés sur votre type de champ personnalisé. Cette classe doit hériter de SPField ou de l’une des classes dans SharePoint Foundation qui en dérivent. La classe est compilée dans un assembly à nom fort et vous la déployez dans le Global Assembly Cache. Dans le contexte d’un affichage de liste, un objet SPField représente une colonne et ses propriétés, telles que la possibilité ou l’impossibilité de trier celle-ci. Dans le contexte des modes Affichage, Nouveau et Modifier, un objet SPField représente un champ particulier d’un élément de liste (une cellule du tableau qui constitue la liste) et la valeur de cette cellule dans la base de données de contenu.

Éventuellement, cette classe peut contenir une validation de données personnalisée pour votre type de champ. Pour plus d’informations sur la validation personnalisée, voir Validation des données du champ personnalisé.

Pour plus d’informations sur les classes de champ personnalisées, voir Procédure : créer une classe de champ personnalisé.

3. (Facultatif) Créer une feuille de style XSLT personnalisée

La façon standard dont SharePoint Foundation restitue les champs sur un affichage de liste consiste à utiliser des feuilles de style XSLT. Par défaut, les feuilles de style prédéfinies de SharePoint Foundation restituent simplement la valeur du champ en texte brut. Si vous souhaitez appliquer un rendu différent sur les affichages de liste, l’ingrédient de base de votre système pour le rendu de votre champ personnalisé est une feuille de style XSLT personnalisée. Vous la nommez selon le modèle fldtypes_*.xsl et la déployez dans %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\LAYOUTS\XSL. Votre feuille de style personnalisée est prioritaire sur la feuille de style par défaut.

L’en-tête au-dessus d’une colonne dans les affichages de liste est également restitué par une feuille de style XSLT et, là encore, vous créez une feuille de style pour substituer la feuille de style prédéfinie si, et uniquement si, vous avez besoin d’un rendu non standard de l’en-tête de colonne pour votre type de champ personnalisé.

Pour plus d’informations sur la création d’une feuille de style XSLT pour votre champ personnalisé, voir Procédure : personnaliser le rendu d’un champ d’un affichage de liste.

Notes

Si vous disposez d’un type de champ personnalisé hérité développé sous une version antérieure de SharePoint Foundation, et s’il s’affichait différemment sur les affichages de liste par rapport au rendu par défaut fourni par l’infrastructure de rendu XSLT, vous pouvez désactiver le rendu XSLT du champ. Pour ce faire, vous ajoutez <Field Name="CAMLRendering">TRUE</Field> en tant qu’enfant de l’élément FieldType dans le fichier fldtypes*.xml qui contient la définition Langage CAML (Collaborative Application Markup Language) du champ personnalisé hérité. Ainsi, le champ et l’en-tête de colonne sur les affichages de liste sont restitués conformément aux schémas RenderPattern. Pour plus d’informations, voir RenderPattern, élément (Types de champs).

4. Créer une classe de contrôle de rendu

Conjointement avec un modèle de rendu (voir la prochaine section), une classe de contrôle de rendu permet de restituer vos champs dans les modes Nouveau, Modifier ou Affichage. Cette classe doit hériter de BaseFieldControl ou de l’une des classes dans SharePoint Foundation qui en dérivent. Cette classe est compilée dans le même assembly que la classe de champ.

La logique de validation est implémentée par les membres Validate, IsValid et ErrorMessage du contrôle de rendu de champ et par la méthode GetValidatedString du type de champ sous-jacent. (Validate peut être appelé par CreateChildControls.)

Pour plus d’informations sur les contrôles de rendu, voir Procédure : créer un contrôle de rendu de champ.

5. Créer un ou plusieurs modèles de rendu

À chaque contrôle de rendu de champ est associé au moins un modèle de rendu de champ pour restituer un champ en mode Nouveau, Modifier ou Affichage. Pour effectuer l’association, vous devez faire en sorte que le contrôle de rendu de champ contienne dans l’une de ses propriétés une référence à l’ID du modèle de rendu de champ. Au moment du rendu, SharePoint Foundation recherche le modèle nécessaire d’après les ID de tous les modèles de rendu déclarés dans les fichiers .ascx du dossier %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\CONTROLTEMPLATES (tous chargés au démarrage de l’application Web). La méthode CreateChildControls du contrôle de rendu apporte souvent une touche finale au rendu du champ, mais la plus grande partie du travail de rendu est effectuée par le modèle. En règle générale, la méthode CreateChildControls attribue des valeurs par défaut aux contrôles enfants du contrôle de rendu en mode Nouveau. Elle attribue les valeurs actuelles du champ aux contrôles enfants en mode Modifier et Affichage. Il est possible qu’elle apporte d’autres touches finales au rendu telles que l’affectation d’une classe CSS à un contrôle Label enfant.

En règle générale, deux modèles de rendu sont nécessaires : l’un restitue le champ dans un formulaire modifiable dans les modes Nouveau et Modifier, tandis que l’autre le restitue dans un formulaire en lecture seule en mode Affichage. Toutefois, si vous le souhaitez, il est possible que les trois modes partagent le même modèle de rendu ou que chacun dispose de son propre modèle de rendu. Vous pouvez même disposer de plusieurs modèles pour un mode donné, avec une logique qui appelle l’un ou autre en fonction des aspects du contexte, tels que le contexte utilisateur ou le type de liste ou de site sur lequel le champ apparaît.

Pour plus d’informations sur les modèles de rendu, voir Procédure : créer des modèles de rendu de champ.

Un modèle de rendu pour les modes Nouveau et Modifier nécessite généralement des contrôles interactifs tels que les zones de texte modifiable, les cases à cocher, les cases d’option et les contrôles de liste déroulante en guise de contrôles enfants. En revanche, le mode d’affichage ne requiert normalement que les contrôles Label ou Literal ou d’autres contrôles d’affichage statique. Par conséquent, vous devrez probablement créer un modèle de rendu spécifique pour le mode d’affichage. Vous spécifiez ce modèle (par ID) dans la propriété DisplayTemplateName. Le modèle principal à utiliser en dehors du mode Affichage est spécifié par la propriété TemplateName().

Le modèle de rendu effectivement utilisé pour restituer le champ dans tout contexte donné est celui retourné par la propriété ControlTemplate du contrôle de rendu. L’accesseur get de cette propriété effectue une sélection parmi les modèles de rendu associés au contrôle de rendu, en utilisant des critères de décision tels que les suivants :

Quel est le contexte HTTP actuel ?
Quel est le mode de contrôle ?
Le champ est-il obligatoire ?
Si le champ est numérique, est-il nécessaire de le restituer sous la forme d'un pourcentage ?
L'élément de liste est-il un dossier ?

Vous pouvez remplacer cette propriété et faire en sorte que son accesseur get vérifie le mode de contrôle et retourne DisplayTemplate en mode d’affichage. (À moins qu’il n’ait été explicitement défini sur un modèle spécifique, DisplayTemplate retourne le modèle identifié par DisplayTemplateName.) À moins que vous n’ayez besoin d’une autre logique de décision dans l’accesseur get pour ControlTemplate, vous pouvez l’amener à appeler l’accesseur get de la propriété de base en mode Nouveau ou modifier.

Notes

Un autre moyen de désigner un modèle de rendu en mode d’affichage consiste à faire en sorte que la méthode CreateChildControls affecte DisplayTemplateName à TemplateName en mode d’affichage. (À moins qu’elle n’ait été remplacée, ControlTemplate retourne Template et, à moins que l’accesseur get de cette dernière n’ait été remplacé, elle retourne le modèle identifié par TemplateName.) Un point faible possible de l’utilisation de la méthode CreateChildControls de cette manière est la non-exécution de la méthode dans un contexte dans lequel le champ n’est pas rendu, comme lorsque vous vérifiez la valeur de ControlTemplate dans le modèle objet à des fins de débogage.

6. (Facultatif) Créer un type de valeur de champ

Si vous créez une classe de champ personnalisée qui requiert une structure de données spéciale pour les données de champ, vous pouvez créer une classe de valeur (ou structure) destinée à contenir vos données de champ.

Pour plus d’informations sur la création de classes de valeurs personnalisées, voir Procédure : créer une classe de valeurs de champs personnalisée.

7. (Facultatif) Créer un contrôle d’édition

Tous les types de champs requièrent un nom, un type de données, une description et d’autres propriétés communes. Toutefois, de nombreux types de champs possèdent également des propriétés spécifiques aux champs concernés. Les utilisateurs définissent ces propriétés variables dans l’interface utilisateur lorsqu’ils créent une colonne basée sur le type de champ. En règle générale, un élément dans la définition du type de champ (voir plus haut dans cette rubrique) détermine la façon dont ces contrôles de définition de propriété sont restitués. Toutefois, un contrôle d’édition spécial est parfois requis. Un contrôle de ce type est défini dans un contrôle utilisateur, c’est-à-dire un fichier .ascx qui contient généralement un fichier code-behind qui renferme sa logique. La création d’un contrôle d’édition spécial est recommandée si vous êtes appelé à exécuter des fonctions personnalisées, telles qu’une logique de calcul complexe, la recherche de valeurs dans des sources de données ou l’application d’une validation de données personnalisée aux valeurs qu’un utilisateur peut choisir lors de la configuration d’un nouvelle colonne.

Notes

Un contrôle d’édition pour les propriétés variables ne doit pas être confondu avec les fichiers .ascx de modèle de rendu décrits plus haut. Le modèle de rendu restitue un champ et sa valeur sur une page en vue de la création, de la modification ou de l’affichage d’un élément de liste particulier à partir d’une liste existante, dont les colonnes sont normalement déjà définies. Pour sa part, le contrôle d’édition pour les propriétés variable restitue certaines propriétés du type de champ sur lequel repose la création d’une colonne.

Pour plus d’informations sur le rendu des types de champs personnalisés et sur les contrôles d’édition pour les propriétés variables, voir Rendu des propriétés de type de champ personnalisés et Contrôles d'éditeur pour les propriétés de type de champ.

8. Déployer les éléments

Pour plus de détails sur les emplacements auxquels vous devez déployer les différentes classes et les différents fichiers que vous avez créés, voir Déploiement de types de champs personnalisés.

Différence entre le rendu des champs pour les périphériques mobiles et le rendu des champs pour les ordinateurs

Dans SharePoint Foundation, le rendu des champs à l’aide de contrôles de rendu de champ personnalisés pour les périphériques mobiles est similaire au rendu des champs à l’aide de contrôles de rendu de champ personnalisés pour les ordinateurs. Cependant, gardez à l’esprit les différences suivantes :

Les pages mobiles constituent un jeu de pages totalement différent des pages ordinaires et elles référencent un ensemble de modèles RenderingTemplate différent.
Les modèles RenderingTemplate mobiles sont déclarés dans MobileDefaultTemplates.ascx, et pas dans DefaultTemplates.ascx.
Les contrôles de rendu de champs mobiles possèdent leur propre espace de noms, Microsoft.SharePoint.MobileControls (au lieu de Microsoft.SharePoint.WebControls), et ils dérivent de classes de l’espace de noms System.Web.UI.MobileControls ASP.NET, au lieu de System.Web.UI.WebControls.
La hiérarchie d’héritage des contrôles de rendu de champs mobiles est différente de celle des contrôles de rendu de champs standard. Par exemple, les fonctions de TemplateBasedControl et FormComponent dans le rendu de champs standard sont combinées dans la classe SPMobileComponent.
Les contrôles de rendu de champ personnalisés que vous créez pour des contextes mobiles reposent plus sur la méthode CreateChildControls du contrôle pour restituer un champ, et moins sur le modèle de rendu, que dans le cas des contrôles de rendu de champ personnalisés que vous créez pour les navigateurs d’ordinateur. En outre, pour les contrôles de rendu mobiles personnalisés, vous substituez rarement la méthode CreateChildControls à proprement parler. À la place, vous substituez généralement une ou plusieurs des autres méthodes qui sont appelées par CreateChildControls :
Pour plus d’informations sur le rendu de pages mobiles et les contrôles de rendu de champs personnalisés, voir Système de rendu des pages mobiles et Procédure pas à pas : créer un contrôle de rendu de champ personnalisé pour les pages mobiles.