SharePoint 2010 Modal Dialog JavaScript internal functions

SharePoint 2010 Modal Dialog Basics

I have probably already worked with the Dialog Framework in a SharePoint 2010 environment. These dialogs are a very interesting feature that I really love. They can be used for a lot of things and of course you can create your owns dialogs to display data or ask for user input.

In this post I will describe briefly the basic functions that are documented on the MSDN and which enables you to work with Modal Dialogs. In a second part I will explain the usage of internal JavaScript functions that are not supposed to be called by custom code. You must be aware that these functions are not documented, ultimately your code should not use these functions because future updates could break down your custom features. But sometimes you need to go beyond the provided API when you have

Opening a Modal Dialog

Let’s begin with the easier and most useful part : opening a new Modal Dialog. For testing purpose I advise you to create an ASPX page inheriting from the default Master Page on a blank Team Site. Then you can add this code directly in a script block in the Main ContentPlaceHolder:

 I won’t go further in details about the different options available because you can now see the whole list on MSDN :

ProcessBatchData – Attention à la casse

Voici un post très rapide concernant l’utilisation de SPWeb.ProcessBatchData. J’ai été surpris cette semaine de constater une erreur similaire sur plusieurs blogs. Voici un exemple très simple d’utilisation de ProcessBatchData :

Considérons la ligne 7 : sb.Append("<?xml version=\"1.0\" encoding=\"UTF-8\"?>"); Cet exemple de code fonctionne. Vous le copiez-collez dans Visual Studio, ajoutez la référence vers Microsoft.SharePoint et modifiez l’URL de la Site Collection et ce code fonctionnera pour peu que vous ayez une liste Tasks dans votre Web site. En revanche modifiez la valeur UTF-8 par utf-8 et vous obtiendrez une magnifique ArgumentException lors de l’exécution de ProcessBatchData.

Faites attention lors des copy/paste depuis le Web. J’ai perdu un certain temps il y a quelques jours là dessus 😉

Explorer votre ferme SharePoint

Il y a un bon moment de cela j’avais trouvé par hasard un outil très pratique lorsqu’on développe pour SharePoint : SharePoint Inspector

Cet outil écrit par Gaetan Bouveret permet de consulter simplement et très rapidement les propriétés de bon nombre d’objets de l’Objet Model. Je me sers principalement de cette application pour récupérer des infos du type GUID, Internal name sur des listes ou champs afin de réaliser des tests. Elle offre un gain de temps non négligeable.

Windows Server 2008 R2 – Activer Aero

Sur bon nombre de blogs j’ai lu que pour activer Aero sur Windows Server 2008 R2 il suffisait d’installer la feature “Desktop Experience”, de démarrer le service “Themes” puis clic-droit sur le bureau –> Personalize et on séléctionne le thème Windows Seven.

Sur ma configuration en tous cas cela ne suffit pas, il faut en effet appliquer cette petite manip : Computer –> System properties –> Advanced system settings –> onglet Advanced –> Settings de performance –> Cocher Adjust for best appearance.

Ensuite seulement il est possible de sélectionner le thème Aero.

Custom Application Pages : tips

Indiquer toutes les astuces pour faire des Application Pages :

  • – Master Page : application.master
  • – Comment les déployer
  • – Custom Action
  • – InputFormSection
  • – Les fichiers de ressource RESX (le fait qu’il faut les copier manuellement à chaque fois qu’on fait une modification)
  • – Afficher la page de chargement avec SPLongOperation
  • – Afficher les pages de succès et d’erreur avec SPUtility.RedirectToSuccessPage…
  • – Comment faire une barre de progression pour un traitement long 😉

Les applications pages SharePoint qu’est ce donc? Rien de plus simple, lorsque vous créez un nouveau site SharePoint (Site Actions –> Create), la page qui vous permet de configurer le nouveau site c’est une application page. Celle qui permet de créer un nouveau Content Type? C’est une application page également. La liste serait longue, je pense que vous avez saisi.

Ces Application Pages se trouvent physiquement dans le répertoire 12 HIVE\LAYOUTS. Je rappelle pour ceux qui débutent dans le déploiement de solutions SharePoint que le répertoire 12 HIVE correspond à l’emplacement C:\Program Files\common files\microsoft shared\web server extensions\12 (pour une installation par défaut). Au passage si vous n’avez pas déjà un raccourci de fait sur votre bureau vers cet emplacement faites-en un.

Ce répertoire 12 HIVE\LAYOUTS est mappé à un Virtual Directory sous IIS. Ainsi tous les sites SharePoint peuvent accéder au contenu de LAYOUTS par l’url suivante:
http://[urlsitecollection]/[web]/_layouts
Le [web] est bien sur optionnel, dans le cas d’une Site Collection.

Autrement dit pour ajouter une Application page il suffit d’en créer une à l’intérieur de ce répertoire. Elle sera ensuite accessible par tous les sites SharePoint (quelque soit l’application Web d’ailleurs). Vous comprendrez alors l’importance de ces pages et les nombreuses possibilités qu’elles peuvent offrir. Alors bien sur cela dépend de ce qu’on a le droit d’y faire sur ces pages. Et bien à peu près tout. En effet sur les Application Pages il vous est possible d’exécuter du code exécuté côté serveur et d’accéder à l’Object Model SharePoint, que du bonheur.

Le but de ce post n’est pas de vous expliquer comment créer une Application Page qui permet d’afficher un hello world à l’écran. C’est essentiel c’est sur mais malheureusement la plupart des posts et articles que j’ai pu consulter sur le sujet s’arrêtent là en indiquant “ca y est votre page fonctionne, pour le reste c’est de l’ASP .Net”. C’est vrai, le développement d’une Application Page est identique à celui d’une page ASP .Net classique … enfin presque 😉

Hello World

Bon allez, pour ceux qui ont ouvert ce post sans en regarder d’autre auparavant sur le sujet voici tout de même un Hello World.

On commence par créer un nouveau dossier dans le 12 HIVE\LAYOUTS que vous nommez comme vous le souhaitez dans mon cas “TrainingAppPages”. Dans ce dossier on ajoute un fichier HelloWorld.aspx que vous ouvrez avec Visual Studio bien entendu.

Ensuite du basique

Limiter le nombre de réponses d’une enquête

Bien souvent lors de la mise en place d’un SharePoint il est nécessaire de faire de nombreux ajustements par rapport aux fonctionnalités de base. Il est alors possible de sortir l’artillerie lourde et de développer (ou redevelopper) les fonctionnalités manquantes. On peut également “bricoler” l’existant lorsque les modifications à apporter sont minimes et concernent principalement l’interface utilisateur.

Prenons l’exemple d’une enquête. Le nombre de réponses par utilisateur peut bien entendu être limité mais le nombre de réponses au total est en revanche illimité. Si on utilise ce type de liste pour gérer une liste d’inscriptions à un évènement dont le nombre de places est restreint il va donc falloir effectuer quelques modifications.

La méthode que je vais utiliser est assez simple et peut-être appliquée à de nombreux problèmes : un DataForm WebPart et un peu de Javascript.

Le principe

Ma liste enquête comporte 2 questions : “Serez-vous présent?” et “Combien de personnes vous accompagneront?”.

survey

Lors de la validation à l’aide de l’un des deux boutons Terminer il faut donc vérifier si le nombre maximal d’inscriptions est atteint ou non et afficher un message en conséquence.

Je vais donc commencer par ajouter un DataForm WebPart à la page d’ajout d’un élément NewForm.aspx.
Ce WebPart récupérera le nombre total d’inscriptions déjà enregistrées puis générera du JavaScript pour effectuer la validation.

DataForm WebPart

Je commence par ajouter un DFWP (DataForm WebPart) à la page NewForm.aspx de ma liste enquête à l’aide de SharePoint Designer. Je l’ajoute juste après le ListForm WebPart dans la zone de WebPart.

Note : Il faut absolument éviter de modifier le ListForm WebPart déjà présent qui permet d’afficher le formulaire d’ajout d’un nouvel élément. Ne supprimez d’ailleurs jamais ce WebPart d’une page NewForm ou EditForm. Si vous souhaitez le remplacer cachez-le (attribut IsVisible).

Pour ajouter le DFWP : menu Vue de données –> Insérer une vue de données. Ensuite dans le panneau “Bibliothèque de sources de données”, clic sur le nom de la liste enquête –> “Afficher les données”.
On séléctionne alors la colonne “Serez-vous présent?” (ou n’importe quelle autre colonne puisque de toutes façons nous allons supprimer l’affichage qui sera généré par SharePoint Designer) puis “Insérer les champs sélectionnés en tant que” –> “Affichage de plusieurs éléments”.

dfwp_original

Filtrons maintenant les éléments retournés. En effet nous n’avons pas besoin de prendre en compte ceux dont la case “Serez-vous présent?” n’est pas cochée. On ouvre les tâches du DFWP (petite flèche en haut à droite du WebPart lorsqu’il est sélectionné) puis “Filtrer”. On indique alors que la colonne “Serez-vous présent?” doit avoir la valeur “Oui”.

dfwp_filter

Toujours dans les tâches du DFWP j’ajoute un paramètre “Limit” qui me permettra de configurer rapidement le nombre maximal de personnes pouvant s’inscrire.

dfwp_parameters

Dans l’affichage Code il va maintenant falloir faire le ménage. En effet je n’ai pas besoin d’afficher les différents éléments, je recopie donc simplement la variable Rows dans le template principal et je supprime les autres templates.

Il ne me reste alors plus que ca:

Ayant recopié tout le WebPart on s’y perd un peu. La seule partie qui nous intéresse pour le moment c’est celle qui se trouve entre les balises <XSL></XSL> :

C’est déjà plus clair. On remarque que mon template ne fait absolument rien pour le moment. Je vais commencer par rajouter quelques variables :

La variable “inscrits” contient donc le nombre total d’enregistrements retournés. Sachant que j’ai défini un filtre auparavant on n’obtient le nombre total d’enregistrements dont la valeur de “Serez-vous présent?” est égale à “Oui” c’est à dire le nombre d’inscrits.

La variable “inscripts_plus” contient le nombre d’accompagnateurs au total grâce à la fonction sum. Vérifiez bien que le paramètre concorde avec le votre.

Enfin je stocke le nombre d’inscrits au total dans la variable “total”.

JavaScript

Maintenant que le DFWP est configuré et qu’il me retourne les valeurs dont j’ai besoin il ne me reste plus qu’à ajouter le code JavaScript permettant de faire la validation. Je l’ajoute dans le template XSL juste après les variables:

L’utilisation de <xsl:value-of/> me permet d’injecter la valeur des variables XSL dans le code JavaScript.
Je récupère les différents éléments à l’aide de la fin de leurs IDs ce qui me permet de copier ce Webpart d’une enquête à l’autre. En effet l’id des contrôles est construit sur l’ID du Webpart et sur d’autres éléments fixes (TextBox, BooleanField, diidIOSaveItem).

Au final l’utilisateur obtiendra un message d’erreur (alert) lorsque le nombre d’inscriptions est dépassé.

result

Modification du paramètre Limit

Comment modifier rapidement le paramètre permettant de limiter le nombre d’inscriptions? Soit vous ouvrez SharePoint Designer et vous modifier la valeur par défaut soit vous utilisez votre navigateur.

Pour cela affichez la page NewForm.aspx de votre enquête où se trouve le DFWP. Ajoutez alors à l’URL le paramètre “ToolpaneView” avec une valeur de 2. Ce qui donne http://[urldel’application]/[site]/[enquete]/NewForm.aspx?Source=[URLderetour]&ToolpaneView=2. C’est ce qu’on appelle le ToolpaneView Hack.

La page s’affiche alors en mode d’édition. Si votre DFWP se trouve bien dans la zone de Webpart (à vérifier dans le code) alors vous avez la possibilité de le modifier. Dans le panneau de modification utilisez l’éditeur de paramètres pour modifier la valeur de Limit. Vous devez enregistrer les modifications puis quitter la page et y revenir pour vérifier le résultat.

Conclusion

L’exemple que je donne ici est très simple et il manque certaines étapes de validation. On pourrait par exemple désactiver le formulaire lorsque le nombre d’inscriptions est atteint. Il serait également plus intuitif d’afficher le nombre de places restantes sur le formulaire. Tout cela es bien entendu possible en JavaScript.

Le but de cet exemple était donc de montrer que l’utilisation d’un DFWP peut aller bien au délà du simple affichage de données et qu’il se révèle très pratique dans de nombreux cas.

Custom Field Types / Colonnes personnelles – PART 2

Dans mon post Custom Field Types – Part 1nous avons vu comment créer une colonne personnalisée très simple. Voyons maintenant comment créer une colonne personnalisée de type recherche (Custom Lookup Field Type) capable de filtrer les éléments grâce à une requête CAML. Si vous n’avez jamais développé ce type d’élément alors consultez mon premier post.

Le contexte

Voici le problème qui m’a ammené à m’intéresser aux Custom Field Types. Imaginons une liste de tâches “Affaires” et une autre liste de tâches “Actions”. Les affaires correspondent à des demandes clients et sont susceptibles de nécessiter la création de plusieurs actions afin de répondre à la demande.
Le plus simple est donc d’ajouter dans la liste Actions une colonne Affaire de type recherche. Cependant lorsque les Affaires passent en état “Terminé” il est toujours possible de créer des actions qui y sont liées. Ainsi après une période d’utilisation assez longue le nombre d’affaires est bien trop important et la création d’une action devient très fastidieuse.

Comment créer une colonne de type recherche avec un filtre sur les éléments recherchés? La solution la plus efficace est de mettre en place un Custom Lookup Field Type.

Le projet

Voici la structure du projet créé à l’aide de STSDEV (utilisez le type Empty Solution with C# assembly):

structure_projet On retrouve tous les éléments que nous avons utilisé dans l’exemple précédent:
Une classe pour notre FieldType (FilteredLookup2Field.cs).
Une classe pour le BaseFieldControl qui servira au rendu de notre colonne (FilteredLookup2Control.cs).
Le fichier XML Fldtypes qui contient la définition de notre Field Type.
Un fichier contrôle utilisateur qui sera lié à notre BaseFieldControl (FilteredLookup2Control.ascx).

Note : dans votre projet vous ne devriez pas avoir de dossier FEATURES et IMAGES ni de classe FeatureReceiver. Il s’agit ici d’une erreur de ma part lors de la création du projet.

FLDTYPES

Je ne reviendrai pas précisement sur le contenu de ce fichier. Seul le contenu de l’élément ParentType diffère et prend la valeur “Lookup”.
Les éléments Field qui se trouvent dans PropertySchema définissent les propriétés de la colonne qui seront demandées lors de l’ajout / édition de la colonne. Dans notre exemple on définit une propriété permettant de configurer la colonne sur laquelle porte la recherche et une seconde pour indiquer la requête CAML à utiliser.

Voici le résultat :

proprietes

SPFieldLookup

Il vous ensuite créer une classe héritant de SPFieldLookup dont le code correspond au comportement de votre colonne. Dans notre exemple il s’agit de la classe FilteredLookup2Field.

Reprenez les différents éléments de la classe MyFirstCustomField du projet précédent. Nous allons overrider une méthode supplémentaire : OnAdded. Celle-ci sera appelée lors de l’ajout de notre colonne à une liste.

Ligne 3 : GetCustomProperty(“LookupList”) permet de récupérer la valeur saisie pour la propriété LookupList lors de l’ajout de la colonne.

Ligne 9 : étant donné qu’on hérite de SPFieldLookup il nous est possible de définir la valeur des propriétés LookupList, LookupWebId et LookupField. Cette étape est indispensable pour que votre colonne soit véritablement liée à la liste recherchée. Votre colonne bénéficiera alors de toutes les fonctionnalités d’une colonne de type recherche (liens vers les éléments de la liste recherchée, mise à jour de votre colonne lors de modifications sur les éléments de la liste recherchée, etc…).

OnAdded est appelée après l’ajout de votre colonne à la liste et non pendant (comme son nom l’indique d’ailleurs). Ainsi les modifications que vous apportez doivent être suivies de this.Update() pour les appliquer. De même si les propriétés de la colonne sont incorrectes on ne peut pas annuler l’ajout de la colonne, il faut la supprimer d’où l’utilisation de this.Delete().

Web User Control

Notre contrôle utilisateur devra contenir une DropDownList pour afficher les éléments de la liste recherchée. Il serait également intéressant de pouvoir activer ou non le filtre CAML. Nous allons donc ajouter une CheckBox pour cela.

 

 

N’oubliez pas d’inclure vos contrôles dans un SharePoint:RenderingTemplate et de définir un ID qui vous permettra d’accéder à ces contrôles depuis le code behind.

BaseFieldControl

Il ne nous reste plus qu’à implémenter le code-behind de notre contrôle. Dans notre exemple c’est la classe FilteredLookup2Control qui s’en charge. Celle-ci hérite de BaseFieldControl.

Ici nous devons prendre en compte de plusieurs problèmes:

  • Que se passe-t-il lorsque la liste recherchée est vide et que notre colonne est un champ obligatoire?
  • Que se passe-t-il lorsqu’on édite un élément et que l’élément recherché a été modifié et qu’il est désormais filtré par la requête CAML?
  • Vérifier les autorisations de l’utilisateur sur la liste recherchée et ses éléments.

Dans cet exemple nous prendrons en compte les deux premiers problèmes je vous laisse gérer le problème de sécurité 😉

Commeçons par définir le DefaultTemplateName qui nous permettra d’accéder aux contrôles:

Passons maintenant à l’initialisation des contrôles:

Vous remarquerez que nous stoppons l’exécution de la méthode lorsque la colonne est en mode d’affichage (ControlMode == SPControlMode.Display). En effet le rendu d’une colonne en mode affichage doit être défini dans le fichier XML fldtypes grâce à l’élément RenderPattern (cela n’est pas obligatoire mais c’est la méthode la plus courante). Nous n’allons donc ici traiter que de l’affichage de la colonne en mode d’ajout / édition.

Ici nous accédons aux contrôles à l’aide du TemplateContainer. Cela ne fonctionne que si vous avez correctement overrider la propriété DefaultTemplateName.

On initialise ensuite notre DropDownList à l’aide de la méthode DropDownListLookup_Init en précisant qu’il faut filtrer les éléments.

Voici la méthode DropDownListLookup_Init en question:

Ici on récupère la liste recherchée et la requête CAML à l’aide des Custom Properties.
On recherche alors les éléments de notre liste en appliquant ou non le filtre CAML en fonction du paramètre filter.
Si aucun élément n’est retourné (pas d’élément dans la liste recherchée ou bien tous filtrés) on ajoute un élément vide dans la DropDownList. Dans le cas contraire on charge les éléments dans notre liste déroulante. On pense à respecter le format ID;#Title pour la valeur des éléments. En effet c’est sous ce format que sont stockées les valeurs d’un champ de type recherche.

Nous allons maintenant ajouter une méthode permettant de sélectionner le bon élément de notre DropDownList en fonction de la valeur de notre colonne. Nous la nommerons DropDownListLookup_SelectIndex.

On commence par caster la valeur du champ en SPFieldLookupValue ce qui facilite ensuite la manipulation de cette valeur.
Si la DropDownList contient la valeur c’est qu’elle n’a pas été filtrée, dans ce cas on sélectionne tout simplement l’élément correspondant. En revanche si la valeur est introuvable c’est qu’elle a été filtrée. On ajoute donc cette valeur à notre DropDownList mais on désactive cette dernière.

Voyons comment obtenir et définir la valeur de notre contrôle à l’aide de la propriété Value:

Pour ce qui est de récupérer la valeur rien de plus simple. On récupère la SelectedValue de notre DropDownList que l’on cast en SPFieldLookupValue. Etant donné que le format des valeurs de la liste déroulante correspond à celui d’une valeur de type recherche cela ne pose aucun problème.

La mise à jour de la valeur de notre contrôle est tout aussi simple puisqu’en réalité nous l’avons déjà traitée dans la méthode DropDownListLookup_SelectIndex().

Gérons maintenant l’activation / désactivation du filtre à l’aide de la CheckBox. Vous aurez remarqué que nous avons abonné la méthode CheckBoxEnableFilter_CheckedChanged à l’event CheckedChanged de notre CheckBox.

On réinitialise la liste déroulante en appliquant le filtre ou non en fonction de l’état coché ou non de la checkbox.

Dernière étape : la validation. En effet si la colonne est un champ requis et que la liste recherchée est vide ou bien que tous les éléments sont filtrés, il faut empêcher la validation de notre contrôle. Dans ce cas ou notre colonne n’est pas un champ requis on laisse passer 🙂
Nous devons donc overrider la méthode Validate:

On vérifie si notre élément vide a été ajouté à la liste déroulante. Si c’est le cas et que la colonne est requise alors on indique que la validation a échoué et on précise le message d’erreur. Celui-ci sera automatiquement affiché à la suite de nos contrôles définis dans FilteredLookup2Control.ascx

Il ne vous reste alors plus qu’à déployer votre projet 🙂

Pourquoi je ne peux pas déboguer mon projet?

Vous aurez probablement besoin de debuger votre projet. Pour cela clic-droit sur le nom de votre projet dans l’explorateur de solutions de Visual Studio –> Onglet générer. Sélectionnez une configuration autre que DebugBuild et cochez la définition des constantes DEBUG et TRACE. Répétez l’opération pour les autres configurations (DebugRedeploy, DebugQuickCopy, etc…). Vous pouvez ensuite attacher Visual Studio au processus w3wp.

Démonstration

Voici une petite démonstration du projet une fois déployé:

 
Filtered lookup field

Custom Field Types / Colonnes personnelles – PART 1

Le développement sous SharePoint est souvent associé aux WebParts, Event Handlers et Workflows. Néanmoins ce n’est pas tout, il est possible de développer bien d’autres éléments pour SharePoint. C’est le cas des colonnes personnelles encore appelées “Custom Field Types”. Qu’est ce que c’est et à quoi ca sert?

Lorsque vous ajoutez une colonne à une liste SharePoint vous avez le choix entre plusieurs types de colonnes en fonction des données que vous souhaitez y stocker. Et bien un custom field type correspond à un type de colonne que vous avez développé vous même avec vos petits doigts musclés. Les possibilités sont très intéressantes.

Je vous donne donc pour cette première partie un exemple très simple de Custom Field Type qui ne sert pas à RIEN pour le moment. Au final (dans quelques posts) vous disposerez d’une colonne recherche avec filtre CAML. Dans cet exemple la colonne sera composée de deux Textbox : Prénom et Nom. Les valeurs seront alors stockées sous la forme prénom;nom mais seront restituées correctement lors de l’affichage.

Le principe

Les différents types de colonnes sont définis par des fichiers XML dont le nom commence par fldtypes et qui se trouvent dans le 12 HIVE\TEMPLATE\XML (12 HIVE correspond au répertoire C:\Program Files\Common Files\Microsoft Shared\web server extensions\12).

Nous allons donc déployer un certain nombre d’éléments dont un fichier fldtypes qui décrira notre colonne. Ce fichier référence une classe héritant de SPFieldText qui gèrera le fonctionnement global de notre colonne (c’est elle qui définit sous quel format la valeur de la colonne est récupérée, quel contrôle est chargé de l’affichage).

Cette classe permettra d’instancier un contrôle de rendu (classe héritant de BaseFieldControl dans notre cas) qui se charge d’effectuer le rendu de la colonne en mode “New” et “Edit” (nous verrons en temps voulu comment se fait l’affichage en mode “Display”). Comme si tout cela n’était pas déjà assez compliqué nous allons également utiliser un modèle de rendu de champ (fichier ascx à placer dans 12\TEMPLATE\CONTROLTEMPLATES) dont je détaille l’utilisation dans l’étape 3.

Etape 1 : Création du projet

Chose importante : il vous faut STSDEV. Si vous ne connaissez pas cet outil merveilleux alors surfez au plus vite sur http://www.codeplex.com/stsdev des vidéos de démo sont disponibles. Créez alors un projet nommé “MyFirstCustomField” de type “Empty Solution (C# assembly)” à l’aide de STSDEV. Ouvrez ensuite la solution générée avec Visual Studio.

Etape 2 : fldtypes

Si vous avez regardé les vidéos présentes sur le codeplex STSDEV vous devriez avoir compris que le répertoire RootFiles de votre projet Visual Studio correspond au 12 HIVE. Créez donc un dossier TEMPLATE dans RootFiles puis un dossier XML dans TEMPLATE et ajoutez-y un fichier fldtypes_myfirstcustomfield.xml. Important : le nom du fichier DOIT commencer par fldtypes.

TypeName : correspond au nom interne de votre champ.
ParentType : type de contenu parent. Pour le moment nous utiliserons Text par la suite nous choisirons Lookup pour créer un champ de type de recherche.
TypeDisplayName : nom de votre colonne utilisé dans l’interface utilisateur SharePoint.
TypeShortDescription : description utilisée lors de l’ajout de la colonne à une liste
FieldTypeClass : référence complète de la classe associée à votre custom field. Pour le moment nous n’avons pas créé cette classe mais cela ne nous empêche pas de renseigner la propriété.

Comment obtenir la valeur de FieldTypeClass?
Si vous débutez dans le développement de solutions SharePoint c’est peut-être la question que vous êtes en train de vous poser. Sachez que le code que vous déployez doit être signé pour être utilisé par SharePoint. C’est pour cela qu’à la création de votre projet avec STSDEV un fichier de clé vous a été demandé. C’est à cela que sert le PublicKeyToken. Le plus simple pour récupérer notre valeur est d’utiliser un petit utilitaire bien connu des codeurs .Net : Reflector.
Commencez par générer votre solution (en mode DebugBuild) puis ouvrez la DLL générée (MyFirstCustomField.dll) à l’aide de Reflector.

La valeur Name correspond donc à notre assembly. C’est un bon début mais ce n’est pas suffisant. En effet la propriété FieldTypeClass n’indique pas l’assembly mais la classe qui sera utilisée. On rajoute cette information sous la forme Namespace.Classe ce qui nous donne dans notre cas: MyFirstCustomField.MyFirstCustomField, MyFirstCustomField, Version=1.0.0.0, Culture=neutral, PublicKeyToken=4d2fbb5068cc2292.
Ici le namespace est donc MyFirstCustomField et la classe se nommera MyFirstCustomField également.

Etape 3 : Le rendu

Dans ce type de projet le rendu est relativement important puisque c’est justement l’intérêt d’un Custom Field : effectuer un rendu personnalisé des données contenues dans les listes SharePoint. Le fonctionnement est similaire à celui des Web UserControl que l’on utilise en ASP .Net.

Voyons cela en détail…

Ajoutez un fichier XML “MyFirstCustomFieldControl.ascx” dans RootFiles\TEMPLATE\CONTROLTEMPLATES (à vous de créer l’arborescence). Voici son contenu:

Maintenant nous allons créer le code-behind. Ajoutez une classe “MyFirstCustomFieldControl” à la racine de votre projet.

Vous remarquerez la présence d’un contrôle RenderingTemplate, il est obligatoire! C’est grâce à ce contrôle que SharePoint fait le lien entre votre fichier ASCX et votre code behind (et oui rien à voir ici avec les classes partielles des User Controls d’ASP .Net).

Ajoutez maintenant une classe publique “MyFirstCustomFieldControl” à la racine de votre projet et faites la hériter de BaseFieldControl. Première chose à faire : overrider la propriété DefaultTemplateName afin de pouvoir faire le lien entre notre contrôle de rendu et le modèle de rendu de champ

 

Important: la valeur retournée par cette propriété doit correspondre à l’ID du RenderingTemplate.

Comment accéder à nos contrôles depuis le code behind? Commencons par les déclarer comme membres de la classe:

 

On override CreateChildControls pour récupérer et initialiser les contrôles:

 

 

Le code est ici très simple puisque nous n’avons aucun traitement à réaliser. On se contente simplement de récupérer les contrôles qui se trouvent dans le RenderingTemplate. Notez que notre contrôle ne sera pas utilisé pour l’affichage du champ ce qui explique le return lorsque ControlMode est à Display.

Il nous reste maintenant à définir comment récupérer la valeur de notre champ et comment initialiser nos contrôles lors de l’édition (il faut en effet récupérer la valeur existante et initialiser nos éléments en conséquence). Cela se passe dans la propriété Value:

 

 

Ici le traitement est très simple. On stocke les valeurs des textbox sous la forme prenom;nom et lorsque l’on Set la valeur du champ on récupère chaque partie que l’on assigne sur la bonne textbox.

Etape 4 : MyFirstCustomField.cs

Il ne nous reste plus qu’à créer la classe qui va représenter notre Custom Field. Cette classe permet de gérer les évènements qui se produisent lorsqu’une colonne de ce type est ajoutée, modifiée, supprimée. Elle permet également de gérer les différentes propriétés associées à la colonne et d’indiquer le contrôle à utiliser pour effectuer le rendu.

Ajoutez donc une classe “MyFirstCustomField” à la racine de votre projet. Déclarez la classe public et faites la hériter de SPFieldText. Définissez les deux constructeurs suivants:

On indique maintenant quel contrôle utiliser pour effectuer le rendu à l’aide de la propriété FieldRenderingControl:

 

 

Etape 5 : RenderPattern

On y est presque, la colonne s’affiche lors de l’ajout et de l’édition et est capable d’enregistrer des valeurs. Néanmoins les valeurs stockées le seront sous la forme prénom;nom. Etant donné que le type parent de la colonne est Text, ces valeurs seront rendues sous ce format lors de l’affichage. La plupart du temps lorsque l’affichage des valeurs est peu complexe on utilise le CAML et les RenderPatterns. Dans notre exemple j’utilise un petit bout de code Javascript pour formater la valeur de la colonne. Voici le contenu du fichier fldtypes_myfirstcutomfield.xml une fois le RenderPattern ajouté:

Je vous l’accorde ce n’est pas très esthétique et surtout ca risque de planter assez facilement si on s’amuse à mettre n’importe quoi comme valeur. Cela vous permet néanmoins de vous faire une idée.

Vous remarquerez l’utilisation de l’élément Column qui fait référence à la valeur de la colonne.

Etape 6 : le déploiement

Voilà c’est terminé (ouf). Il ne vous reste plus qu’à utiliser la cible “DebugDeploy” de votre projet et à générer la solution. Si vous modifiez votre code je vous conseille d’utiliser ensuite la cible “DebugRedeploy”

Ajout de la colonne

Ajout élément

 Affichage liste

Dans la prochaine partie nous verrons comment modifier ce projet afin de créer une colonne de type recherche sur laquelle nous pourrons configurer une requête CAML afin de filtrer les éléments.

Adieu Lycos, bonjour Ikoula

Et oui Lycos Hébergement ferme ses portes. L'activité ne serait plus suffisament rentable et le groupe a donc décidé d'y mettre un terme. Je vous laisse imaginer ma tête lorsque j'ai reçu le premier message d'avertissement à ce sujet. J'avais choisi Lycos il y a bien 7 ans de cela car c'était tout simplement l'un des plus connus, j'étais sur qu'il n'arriverait jamais rien à mes données. Raté.

Heureusement les clients ont été prévenus à temps afin de pouvoir migrer les données en toute sérénité. Néanmoins pour ma part je n'ai jamais réussi à joindre le support technique de Lycos, ils étaient déjà partis.

Il a donc fallu que je trouve un nouvel hébergeur pour Wawawum ainsi que deux autres sites dont je m'occupe sur le plan technique. Je commence par voir du côté d'OVH, celui dont j'entends le plus parler. Je tombe alors sur des offres qui me surprennent: 2,4Go pour un 240 PLAN (nom du pack) à 8,47€ TTC par mois, 7,2Go pour un 720 PLAN à 17,44€ TTC par mois. Mais bon sang moi j'ai besoin d'espace, de liberté !!! Où vais-je pouvoir stocker d'éventuels WebCasts avec aussi peu d'espace Web?
Ce qui m'étonne encore plus c'est de voir que l'espace Web est réduit au profit de l'espace destiné aux e-mails. Sur le 720 PLAN il est indiqué 1000 comptes e-mails de 2Go. J'aimerais qu'on m'explique, s'agit-il de 1000 comptes mail qui peuvent au total consommer 2Go d'espace? Merci de commenter sur ce point.

Bref, j'ai regardé les offres de plusieurs hébergeurs mais elles étaient toutes similaires à celles que je viens de décrire. Impossible pour moi de migrer mes sites qui jusque là bénéficiaient de 10Go d'espace pour plus ou moins 150€ par an domaine compris.

Heureusement mon cher colloc m'a trouvé l'hébergement de mes rêves, merci Moh. Me voici donc avec un serveur virtualisé tournant sous Windows Server 2008 Enterprise Edition ce qui me permet de faire tourner des sites aussi bien en PHP qu'en ASP.Net. De quoi profiter des 20 Go d'espace disque qui me sont alloués. Je tiens également à souligner le professionalisme de l'équipe technique qui est allée jusqu'à m'appeler sur mon numéro personnel pour s'assurer que j'avais bien compris comment fonctionnait leur offre. J'avais je n'aurais imaginé cela de la part de Lycos. Ah oui j'ai oublié de citer le nom de cet hébergeur : iKoula. J'en suis pour le moment pleinement satisfait, le serveur qui ne dispose pourtant que de 512 Mo de RAM tourne très bien et héberge du coup mes 3 sites pour une vingtaine d'euros par mois.