SharePoint 2007 : personnaliser le comportement par défaut d’un type de colonne natif

SharePoint 2007 fournit un certain nombre de types de colonne natif. Vous pouvez également en créer de nouveau si vous avez des besoins spécifiques, en héritant de SPField ou de l’une de ses dérivées (et en avalant un cachet d’aspirine avant de lire la doc).

Toutefois cette approche pose quelques inconvénients :

  • Un peu complexe (mais bon, c’est notre pain quotidien de développeur SharePoint la complexité)
  • Impossible de “convertir” votre colonne depuis ou vers une colonne native
  • Les outils tiers ne reconnaitrons pas votre colonne
  • quelques bugs qui trainent dans SharePoint (je pense à la page de propriété qui ne sait pas conserver les données et qui impose de réécrire cette page à chaque fois)

Je vous propose ici une alternative, elle aussi un peu complexe, mais qui a l’avantage de conserver les colonnes natives, en changeant simplement leur rendu.

Les “ControlAdapter” à votre secours

Un ControlAdapter est une classe qui va permettre de modifier le rendu d’un contrôle. Initialement prévu pour supporter le rendu pour navigateurs mobiles, les ControlAdapters ont été détournés pour personnaliser le rendu de certains contrôles du Framework sans avoir à toucher au contrôle lui même.

Les plus connus des ControlAdapters sont probablement les ASP.NET 2.0 CSS Friendly Control Adapters 1.0 qui permettent de transformer le rendu des WebControls ASP.Net afin de respecter au maximum les contraintes des standards W3C (plus de

générée, mais des).

Le principe de base consiste à créer un fichier .browser que l’on place dans le dossier App_Browsers de votre application Web. Chaque fichier va définir quand appliquer les ControlAdapter et quels sont les ControlAdapters que vous utiliserez.

Extrait de fichier browser :

L’astuce est ici d’utiliser “Default” pour appliquer ce ControlAdapter systématiquement.

Les ControlAdapters appliqués à SharePoint

SharePoint, en tant qu’application Web ne déroge pas à la règle. En effet, les colonnes SharePoint utilisent des contrôles pour générer l’affichage. La classe SPField implémente une propriété virtuelle FieldRenderingControl qui permet à chaque colonne de définir quel est le contrôle utilisé pour l’édition :

Par exemple, si l’on observe la colonne de type url (Reflector est votre ami):

On voit ici que le contrôle UrlField est utilisé… que nous allons personnaliser grâce à un ControlAdapter.

Implémenter votre ControlAdapter

La première étape consiste à créer votre ControlAdapter. Dans mon cas j’utilise WSPBuilder 1.4 Beta avec Visual Studio 2010, mais vous pouvez employer l’outil de dev SharePoint que vous souhaitez. J’ajoute à la solution une Feature vide à laquelle j’ajoute une classe “DocumentExplorerAdapter” (nous parlerons du packaging plus loin). DocumentExplorer est le nom d’une extension SharePoint en cours de développement que je publierai lorsqu’elle sera terminée.

Ce code ici consiste à ajouter un lien vers ce blog. L’approche que j’ai choisie ici est de surcharger CreateChildControls, tout en appelant base.CreateChildControls. Cela me permet de ne pas modifier le fonctionnement du contrôle, si ce n’est ajouter un lien sous le contrôle. Théoriquement vous pouvez faire ce que vous voulez du contrôle en surchargeant les bonnes méthodes.

Compilez ce code, déployez le (copie dans le GAC ou déploiement du WSP généré si vous préférez) puis aller dans le dossier “C:\inetpub\wwwroot\wss\VirtualDirectories\80\App_Browsers“. Il s’agit du site Web par défaut de ma machine, mais vous devrez peut être adapter ce chemin à votre configuration.

Dans ce dossier, créez le fichier “DocumentExplorerAdapter.browser” (libre à vous de le nommer comme vous le souhaitez) :

N’oubliez pas de mettre à jour le nom de l’assembly dans l’attribut “adapterType”.

Recycler votre pool d’application, et, ô miracle, un lien vers ce blog vient d’apparaitre !

Note : il arrive dans certains cas (non identifiés malheureusement) où le contrôle n’était pas correctement modifié. Pour contourner le problème, ouvrez le fichier compat.browser avec le bloc note, et sauvegardez le. Cette manipulation provoque le parsing des fichiers browser et devrait résoudre le problème.

La problématique du déploiement

Comme tout bon développeur SharePoint qui se respecte, vous devriez avoir eu les cheveux qui se sont dressés sur votre tête à l’évocation de déployer des fichiers à la main. Rassurez vous, je vais vous montrer comment déployer ce fichier browser au travers d’une feature.

La première chose à savoir, c’est qu’il n’existe pas de type de feature permettant d’ajouter des fichiers dans le dossier physique de l’application web. Aussi il va falloir ruser.

Pour déposer ce ficher, je vais créer une feature dont la portée est “WebApplication” et qui possède un FeatureReceiver :

Le nœud ElementManifests reste vide puisque nous ne pouvons pas régler le problème au travers d’un type de feature. Par contre, depuis le FeatureReceiver, nous pouvons créer un job qui pourra faire le travail.

Il est possible de créer les fichiers directement depuis le FeatureReceiver, mais seulement si il n’y a qu’un serveur frontal. En effet, les évènements du FeatureReceiver sont levé depuis le serveur où l’activation a été demandée. Dans le cas d’une ferme de serveur, il est nécessaire de créer un Job personnalisé, avec dans le constructeur SPJobLockType.None. Dans ce cas, le travail sera exécuté sur chaque serveur, et surtout sur chaque nouveau serveur ajouté à la ferme.

Ainsi nous avons le code suivant pour le FeatureReceiver :

J’ai choisi ici de créer un Job personnalisé DocumentExplorerSyncBrowserFilesJob identique pour le déploiement et la suppression du fichier browser. Je créer ce travail (et supprimer une ancienne instance si elle existe) pour s’exécuter immédiatement. En réalité il faut “attendre” quelque secondes du fait du fonctionnement interne du minuteur SharePoint.

Le de ce job est :

Le code de ce job va explorer toutes les applications Web IIS liées à l’application web SharePoint (dans le cas où vous auriez étendu l’application web). Il vérifie ensuite si la feature est activée ou non (si elle est trouvée ou non dans la collection de features de l’application Web SharePoint).

  • Si elle trouvée, le fichier est créé si n’existait pas déjà
  • Si elle n’est pas trouvée, on supprime éventuellement le fichier.

Le résultat : une colonne personnalisée visuellement

Pour vérifier que tout fonctionne, déployons la solution (vive WSPBuilder).

Dans l’administration centrale, vous avez accès à une nouvelle feature au niveau de vos applications web :

Activation de la feature

Après activation (et quelques secondes d’attentes), le fichier apparait :

[text]C:\>dir C:\inetpub\wwwroot\wss\VirtualDirectories\80\App_Browsers /b
compat.browser
DocumentExplorerAdapters.browser

[/text]

Je crée ensuite une colonne de type Lien hypertexte (colonne native) :

Création d'une colonne lien hypertexte

Et lorsque je saisi un nouvel élément :

Le résultat escompté : la colonne est personnalisée

Comme prévu, le lien vers le blog apparait !

Conclusion

Je vous ai ici montré comment personnaliser le rendu des colonnes natives de SharePoint, ainsi que la procédure “propre” pour les packager. Gardez à l’esprit cette possibilité car elle vous permettra de :

  • ajouter des fonctionnalités à votre environnement SharePoint, tout en conservant la compatibilité des données
  • personnaliser si nécessaire le rendu visuel pour s’adapter aux customisations graphiques
Rating 5.00 out of 5
[?]