Cette documentation est archivée et n’est pas conservée.

Schémas de rendu de champ personnalisé

Windows SharePoint Services 3

De nombreuses options vous permettent de contrôler avec précision le rendu des champs personnalisés à l'aide de modèles de rendu de champ. Cette rubrique décrit certains schémas courants et indique comment vous pouvez les modifier pour répondre à vos besoins.

Remarque Remarque :

Cette rubrique traite du rendu des champs personnalisés et de leurs valeurs. Elle n'aborde pas le rendu des propriétés de variable des types de champs personnalisés des pages Nouvelle colonne de site, Modifier la colonne de site, Créer une colonne et Modifier la colonne. Pour plus d'informations sur le rendu des propriétés de champ de variable des types de champs personnalisés, voir Rendu des propriétés de type de champ personnalisés.

Utiliser uniquement des schémas de rendu

La méthode la plus simple pour restituer un type de champ personnalisé ne recourt pas à des contrôles de rendu de champ ou à des modèles de rendu de champ (voir ci-dessous). En effet, le rendu des champs dans tous les modes de contrôle (Nouveau, Modifier et Affichage) ainsi que dans les affichages de listes s'effectue entièrement au moyen de schémas de rendu configurés dans une définition de champ. Toutefois, cette méthode limite votre logique de validation aux opérations réalisables dans les scripts. Par conséquent, vous constaterez probablement que vous ne pouvez utiliser des schémas de rendu que pour le rendu sur les affichages de listes et en mode d'affichage, situations dans lesquelles la validation ne pose pas de problème.

Dans les modes Nouveau et Modifier, vous devrez généralement créer un contrôle de rendu de champ et au moins un modèle de rendu de champ.

Système de modèle et de contrôle de rendu

À chaque contrôle de rendu de champ est associé au moins un modèle de rendu de champ. 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, Windows SharePoint Services 3.0 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 C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\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.

Schéma le plus courant

Le schéma de la configuration du rendu des champs que vous serez amené à utiliser le plus souvent lors du développement de types de champs personnalisés présente les caractéristiques suivantes :

  • La définition du champ personnalisé (dans le fichier fldtypes*.xml) contient un type DisplayPattern de schéma de rendu qui restitue le champ dans les affichages de listes et en mode d'affichage.

  • Il existe un contrôle de rendu, associé à un seul modèle de rendu. Le contrôle utilise sa propriété TemplateName pour spécifier l'ID du modèle.

  • Ce seul modèle permet d'obtenir la majorité du rendu du champ dans les modes Nouveau et Modifier.

  • La méthode CreateChildControls du contrôle de rendu affecte des valeurs par défaut aux contrôles enfants du contrôle de rendu en mode Nouveau. Elle affecte les valeurs actuelles du champ aux contrôles enfants en mode édition. (Elle n'effectue aucune opération en mode Affichage.) En outre, elle peut réaliser des tâches de rendu finales telles que l'affectation d'une classe CSS à un contrôle Label enfant.

  • 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.)

Schémas plus complexes

Cette section décrit quelques-unes des façons dont vous pouvez vous écarter du modèle standard lorsque votre type de champ personnalisé le requiert.

Utiliser un modèle en mode d'affichage

Il peut parfois être préférable d'utiliser un modèle de rendu de champ plutôt qu'un schéma de rendu, même pour le mode d'affichage. Par exemple, plusieurs types de champs personnalisés peuvent sembler pratiquement identiques en mode d'affichage. Il est difficile de réutiliser un RenderPattern dans de nombreux types de champs, à moins d'effectuer une opération copier-coller depuis un fichier fldtypes*.xml vers un autre (ou à l'intérieur d'un fichier de ce type). Toutefois, si vous avez utilisé cette méthode et que vous devez apporter une modification au RenderPattern, vous devez rechercher tous les emplacements auxquels vous l'avez copié. Par conséquent, il peut vous sembler préférable d'utiliser un modèle de rendu de champ pouvant être référencé par de nombreux contrôles de rendu différents.

Il est peu probable que le même modèle soit utilisable pour les trois modes de contrôle. Les modes Nouveau et Modifier nécessitent 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 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 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. Son accesseur get 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 ait été explicitement défini sur un modèle spécifique, DisplayTemplate retourne le modèle identifié par DisplayTemplateName.) À moins que vous ayez besoin d'une autre logique de décision dans l'accesseur get pour ControlTemplate, vous pouvez simplement l'amener à appeler l'accesseur get de la propriété de base en mode Nouveau ou modifier.

Remarque Remarque :

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 ait été remplacée, ControlTemplate retourne Templateet, à moins que l'accesseur get de cette dernière ait été remplacé, elle retourne le modèle identifié par TemplateName.) Un point faible possible de cette approche est la non-exécution du code 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.

Autres situations nécessitant plusieurs modèles de rendu

Outre Template, TemplateName, DisplayTemplate et DisplayTemplateName, vous pouvez également utiliser AlternateTemplate, AlternateTemplateName.

Utilisez un modèle de remplacement pour restituer votre champ personnalisé dans tout contexte de page dans lequel le modèle principal ne répond pas à vos besoins. Voici quelques exemples :

  • Si le champ est requis sur certaines listes, mais pas sur d'autres, vous pouvez recourir à un modèle de remplacement identique au modèle principal, à la différence qu'il ajoute un indicateur, par exemple, un astérisque rouge, signalant que le champ est requis sur des listes spécifiques. Ensuite, faites en sorte que l'accesseur get de ControlTemplate vérifie la propriété Required du champ sous-jacent et retourne Template ou AlternateTemplate selon le cas.

  • Si vous envisagez d'utiliser de nombreux types de champs personnalisés dont le rendu sera pratiquement identique, vous pouvez éventuellement obtenir une meilleure réutilisation du code en créant des modèles distincts pour une utilisation dans les modes Nouveau et Modifier. Le premier affecte des valeurs par défaut aux objets enfants, tandis que le second affecte des valeurs actuelles. Cela vous évite de répéter la logique d'affectation dans la méthode CreateChildControls de chacune des classes de types de champs personnalisés. Là encore, l'accesseur get de ControlTemplate doit déterminer le modèle utilisé en fonction du mode de contrôle.

  • L'utilisation d'un modèle de remplacement peut également être utile lorsque votre champ requiert un rendu spécial sur certains sites Web, certaines collections de sites ou certaines applications Web. Imaginez, par exemple, un site Web conçu pour les personnes présentant une altération visuelle, telle que le daltonisme. L'accesseur get de ControlTemplate peut examiner la valeur de RenderContext pour déterminer si le modèle spécial est requis et retourner le modèle approprié.

  • Pour les types de champs personnalisés qui héritent de SPFieldNumber et qui, parfois, mais pas systématiquement, doivent être restitués sous forme de pourcentages, le recours à deux modèles de rendu différents permet un gain de temps considérable en matière de développement. Substituez l'accesseur get de ControlTemplate pour répondre à la valeur de la propriété Microsoft.SharePoint.SPFieldNumber.ShowAsPercentage.

Ajouter des associations de modèles

Vous pouvez, bien entendu, ajouter des associations de modèles de rendu au contrôle de rendu de champ que vous dérivez de BaseFieldControl. Nous vous recommandons de suivre le schéma suivant :

  • Créez un nouveau champ privé nommé de type ITemplate.

  • Créez une nouvelle propriété publique en tant que wrapper autour du champ privé et attribuez-lui un nom tel que circonstancesModèle, où circonstances identifie les circonstances dans lesquelles vous envisagez d'utiliser le modèle.

  • Créez une seconde propriété publique qui retourne une String et nommez-la circonstancesnom_modèle.

  • L'accesseur get pour circonstancesModèle ne doit retourner le champ privé que si ce dernier n'est pas null. Dans le cas contraire, il doit retourner le ITemplate nommé par circonstancesnom_modèle. Utilisez la méthode GetTemplateByName à cette fin.

  • Substituez l'accesseur get de ControlTemplate pour retourner circonstancesModèle chaque fois que circonstances a pour valeur true.

Utiliser des contrôles Web personnalisés comme modèles

Votre contrôle de rendu de champ personnalisé hérite également deux propriétés ITemplatespéciales :

CustomTemplate et CustomAlternateTemplate. Ces deux propriétés sont marquées avec l'attribut [PersistenceMode(PersistenceMode.InnerProperty)]. Cela signifie que les objets ITemplate qu'elles retournent sont compilés et qu'ils sont conservés dans le contrôle de rendu de champ en tant que balises imbriquées. Il existe plusieurs avantages liés à l'utilisation de modèles précompilés ; par exemple, vous pouvez les ajouter à une page dans un concepteur visuel tel que Microsoft Office SharePoint Designer 2007 ou Microsoft Visual Studio 2005 en les faisant glisser et déplacer depuis la boîte à outils du concepteur. Cependant, il existe également des inconvénients. Pour plus d'informations sur les contrôles utilisateur Web et sur les contrôles Web personnalisés, voir Web User Controls and Web Custom Controls et PersistenceModeAttribute.

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

Dans Windows SharePoint Services 3.0, 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 :

Voir aussi

Afficher: