Ressources et localisation dans ASP.NET 2.0 (Basic Instincts)
Consultez cet article en anglais
Cliquez ici pour télécharger le code de cet article : BasicInstincts2006_08.exe (878 ko)
Sur cette page
Dans mon dernier article, j'ai étudié l'utilisation des fichiers de ressources dans le développement .NET. J'ai internationalisé une application Windows® Forms et je l'ai localisée pour les utilisateurs qui parlent et lisent différentes langues. Ce mois-ci, je vais étudier la localisation des sites Web dans ASP.NET 2.0.
Je suppose que vous êtes familiarisé avec l'interface utilisateur et les paramètres culturels, les objets CultureInfo, les fichiers de ressource, la classe ResourceManager et les classes de ressource fortement typées générées automatiquement. Je suppose également que vous comprenez les mécanismes Microsoft® .NET Framework permettant de déterminer si les ressources doivent être chargées à partir de l'assembly par défaut ou d'un assembly satellite localisé. Si vous avez besoin de davantage d'informations sur ces sujets, lisez mon article Basic Instincts de mai 2006 avant de continuer.
Contrôle des paramètres culturels au niveau page
ASP.NET 2.0 facilite le changement des paramètres culturels page par page Il suffit d'ajouter les attributs UICulture et Culture à la directive Page d'une page .aspx, comme suit :
<%@ Page="" UICulture="fr" Culture="fr-BE" %>
Très tôt dans le cycle de vie de la page, une page .aspx avec ces paramètres initialise la propriété CurrentUICulture et la propriété CurrentCulture du thread en cours avec les objets CultureInfo appropriés. Si vous ajoutez les attributs illustrés ci-dessus à un fichier .aspx au cours des tests, puis vous ajoutez un contrôle Web ASP.NET intégré à la page, tel que le contrôle Calendar, vous voyez immédiatement que cela fonctionne correctement, comme le montre la figure 1. Le contrôle Calendar à gauche s'affiche sur une page avec le paramètre culturel en-US, tandis que le contrôle Calendar à droite s'affiche sur une page avec le paramètre culturel fr-BE.
Figure 1. Contrôles Calendar localisés
Dans la plupart des sites Web de production, il n'est cependant pas judicieux de coder en dur les paramètres culturels dans vos pages. À l'inverse, les utilisateurs qui parlent des langues différentes doivent voir des affichages localisés différents de la même page. ASP.NET peut automatiquement initialiser les paramètres culturels en fonction de la demande si vous affectez la valeur « auto » aux attributs UICulture et Culture.
<%@ Page="" UICulture="auto" Culture="auto" %>
ASP.NET initialise les paramètres en examinant les en-têtes HTTP envoyés par les navigateurs. Vous pouvez tester différentes versions localisées de vos pages dans Internet Explorer® en changeant les paramètres de préférence linguistique dans la boîte de dialogue Options Internet.
En général, vous souhaiterez que toutes les pages de votre site présentent les mêmes paramètres culturels. Vous pouvez affecter à l'échelle du site la valeur « auto » pour les attributs UICulture et Culture, afin de ne pas avoir à intervenir sur chaque page. Ajoutez simplement l'élément suivant dans le fichier web.config à la racine d'un site :
<globalization uiCulture="auto" culture="auto" />
Vous pouvez également spécifier une culture par défaut (en plus du paramètre auto) qui sera utilisée par ASP.NET s'il ne trouve pas d'en-tête HTTP permettant de déterminer la culture préférée de l'utilisateur :
<globalization uiCulture="auto:en" culture="auto:en-US" />
Suivi des préférences linguistiques à l'aide de profils
Si le paramètre auto facilite les choses, il n'est pas toujours commode pour l'utilisateur. Supposons par exemple qu'un utilisateur préfère lire les sites Web techniques en anglais et les sites Web commerciaux en français. Il trouvera très ennuyeux de changer les paramètres du navigateur lors du passage d'un site à un autre. Cet utilisateur appréciera un site Web lui permettant de sélectionner une préférence linguistique.
Pour voir comment créer une interface utilisateur et une implémentation permettant aux utilisateurs de changer facilement de langue, téléchargez l'exemple de code de ce mois-ci, un site Web ASP.NET 2.0 nommé LitwareWebApp. Son interface utilisateur est illustrée figure 2.
Figure 2a. Version en anglais
Figure 2b. Version localisée
Le site LitwareWebApp effectue le suivi des préférences linguistiques de l'utilisateur avec la nouvelle fonctionnalité de profil introduite dans ASP.NET 2.0. Vous pouvez ajouter une propriété de profil de type chaîne nommée LanguagePreference prenant en charge l'identification anonyme en ajoutant les éléments suivants au fichier web.config du site :
<configuration>
<system.web>
<anonymousIdentification enabled="true"/>
<profile>
<properties>
<add name="LanguagePreference" type="string" defaultValue="Auto" allowAnonymous="true" />
</properties>
</profile>
</system.web>
</configuration>
Le site LitwareWebApp est conçu avec une disposition standard dans une page maître contenant un contrôle RadioButtonList nommé lstLanguage. Notez que si ce contrôle affiche des noms de langue explicites, tels que Anglais américain et Français belge, il effectue également le suivi des noms culturels réels, tels que en-US et fr-BE, via la propriété SelectedValue. Lorsqu'un utilisateur change la préférence linguistique, l'événement SelectedIndexChanged du contrôle lstLanguage se déclenche et exécute le code suivant afin de mettre à jour la propriété de profil LanguagePreference :
Profile.LanguagePreference = lstLanguage.SelectedValue
Response.Redirect(Me.Request.Url.AbsolutePath)
L'appel de Response.Redirect force un nouvel aller-retour entre le navigateur et le serveur Web, ce qui fait que le cycle de vie de la page recommence une fois la propriété de profil configurée avec la préférence linguistique souhaitée.
Vous devez ensuite ajuster par programmation le paramètre culturel au moment approprié dans le cycle de vie de la page. Pour faire cela dans ASP.NET 2.0, vous devez remplacer une méthode de la classe Page nommée InitializeCulture. Le cycle de vie de la page a été conçu pour toujours appeler InitializeCulture avant la page proprement dite ou avant que ses contrôles enfant n'aient effectué de travail sur les ressources localisées.
La conception de l'exemple de site nécessite l'ajout d'une implémentation remplacée de InitializeCulture à chaque page du site. Malheureusement, vous ne pouvez pas remplacer la méthode InitializeCulture au niveau d'une page maître, car la classe MasterPage n'hérite pas de la classe Page. En outre, il serait trop fastidieux de remplacer la méthode InitializeCulture séparément pour chaque page d'un site Web. Cela conduirait à de nombreuses implémentations redondantes entraînant un sérieux problème de performance.
Une approche plus efficace de l'initialisation des paramètres culturels à l'échelle du site consiste à créer une classe de base commune dérivée de Page et à faire en sorte que tous vos fichiers de page .aspx en héritent ; c'est ce que j'ai fait dans l'exemple de site LitwareWebApp. Ma classe de base dérivée de Page nommée LitwarePage (voir figure 3) a été définie dans un fichier source nommé LitwarePage, lequel a été ajouté au répertoire App_Code afin qu'il soit automatiquement compilé par ASP.NET et mis à la disposition d'autre code dans le site Web actuel.
Une fois que vous avez créé une classe de base dérivée de Page, vous pouvez mettre à jour vos définitions de page .aspx afin d'en dériver vos classes, plutôt que de la classe Page standard. Par exemple, vous pouvez modifier la classe partielle de default.aspx.vb afin qu'elle ressemble à ceci :
Partial Class _Default : Inherits LitwarePage
'*** page class definition goes here
End Class
À ce stade, je dispose d'un site capable d'effectuer le suivi des préférences de langue des utilisateurs et d'initialiser les paramètres culturels à la demande. Je dois à présent localiser les littéraux de type chaîne pour un site Web ASP.NET 2.0 en utilisant des fichiers de ressource, afin de gérer les utilisateurs qui parlent différentes langues.
Fichiers de ressources dans ASP.NET 2.0
Étant donné que, par défaut, Visual Studio® 2005 n'utilise pas de projets pour gérer les sites Web ASP.NET 2.0, il n'existe pas de fichier de ressources de niveau projet comme il en existe pour une application Windows Forms ou une DLL de bibliothèque de classes. Vous devez en revanche créer explicitement des fichiers de ressources et les ajouter à votre site Web. En outre, vous devez utiliser les dossiers spéciaux introduits dans ASP.NET 2.0 : les fichiers de ressources contenant des ressources globales doivent être ajoutés au dossier App_GlobalResources et les ressources locales propres à un fichier doivent être ajoutées au dossier App_LocalResources. Les ressources globales sont celles pouvant être utilisées à l'échelle du site à partir des pages, ainsi qu'à partir d'autres fichiers, tels qu'un plan du site. Les types de fichier ASP.NET prenant en charge les ressources locales sont les pages (fichiers .aspx), les pages maître (fichiers .master) et les contrôles utilisateur (fichiers .ascx).
Une autre différence avec ASP.NET 2.0 est que vous n'avez pas besoin de compiler à l'avance les fichiers de ressource, comme vous le faites lors du développement d'une application Windows Forms internationalisée. Le runtime ASP.NET compile en effet les fichiers des ressources globales et locales en DLL au moment approprié, comme il le fait avec les fichiers .aspx. Il s'agit là d'une fonctionnalité puissante, car une entreprise peut ajouter la prise en charge de la localisation dans une nouvelle langue en copiant simplement les fichiers .resx avec XCOPY sur un serveur Web de production.
Examinons un exemple de création et d'utilisation d'un fichier de ressources globales dans un site Web ASP.NET 2.0 avec Visual Studio 2005. Vous pouvez créer un nouveau fichier de ressources globales en choisissant la commande Ajouter nouvel élément et en sélectionnant Fichier de ressource.
Lorsque vous cliquez sur le bouton Ajouter afin de créer le nouveau fichier de ressources globales, Visual Studio 2005 affiche une boîte de dialogue qui vous recommande de placer le fichier de ressources dans le répertoire App_GlobalResources. Cliquez sur Oui. Si vous le placez ailleurs, ASP.NET ne compilera pas automatiquement le fichier de ressources en DLL.
L'utilisation de fichiers de ressources dans ASP.NET est analogue à leur utilisation dans une application Windows Forms. Vous commencez par créer un fichier de ressources avec des littéraux de type chaîne, localisés pour la culture par défaut. Dans notre exemple de site Web, il y a pour cela un fichier de ressources globales nommé Litware.resx, comme le montre la figure 4. Une fois que vous avez ajouté toutes les chaînes nommées pour la culture par défaut, vous pouvez copier le fichier de ressources et le renommer en Litware.fr.resx afin de proposer des chaînes localisées en français. Vous pouvez également copier ce fichier de ressources français et le renommer en Litware.fr-BE.resx afin de conserver les chaînes localisées pour le français belge
Figure 4. Ressources localisées
L'ajout et la gestion des chaînes nommées dans un fichier de ressources sont faciles, car Visual Studio 2005 offre l'éditeur de ressource illustré Figure 5. Rappelez-vous que les fichiers de ressources ne vous limitent pas aux chaînes localisées. Vous pouvez ajouter d'autres types de ressource, tels que des fichiers d'image, des feuilles de style CSS et des fichiers JavaScript côté client.
Figure 5. L'éditeur de ressource de Visual Studio 2005
Créons à présent des pages qui extraient les chaînes nommées d'un fichier de ressources globales. C'est très facile. Comme lorsque vous développez une application Windows Forms internationalisée, il n'est pas nécessaire de programmer directement par rapport à la classe ResourceManager fournie par le .NET Framework. Cela tient au fait que ASP.NET et Visual Studio 2005 créent en coulisses une classe de ressource fortement typée pour chaque fichier de ressources globales, qu'ils mettent à disposition via IntelliSense®.
Les chaînes nommées que vous ajoutez à un fichier de ressources globales sont accessibles via une classe fortement typée imbriquée dans un espace de noms de niveau supérieur nommé Resources. Une seule ligne de code est nécessaire pour affecter une chaîne localisée à la valeur de la propriété d'un contrôle :
lblApplicationName.Text = Resources.Litware.ApplicationName
Outre l'accès par programmation, ASP.NET 2.0 introduit également une syntaxe déclarative que vous pouvez utiliser pour lier une chaîne nommée à une propriété d'une page ou d'un contrôle. La syntaxe implique l'utilisation du signe dollar ($) suivi de l'espace de noms Resources, du nom du fichier de ressources et du nom de la chaîne :
<%$ Resources:Litware, ApplicationName="" %>
Par exemple, si vous souhaitez lier la chaîne nommée ApplicationName à la propriété Text d'une étiquette dans une page .aspx, vous pouvez écrire la balise comme suit :
<asp:Label ID="lblApplicationName" runat="server" Text="<"%$ Resources:Litware, ApplicationName="" %>" />
Visual Studio 2005 offre également un outil commode nommé Expression Builder, illustré figure 6. Cet utilitaire peut vous aider à générer la syntaxe requise pour lier les chaînes nommées d'un fichier de ressources aux propriétés des contrôles et des pages. Une fois que vous avez ajouté un ou plusieurs fichiers de ressources avec des chaînes nommées, vous pouvez accéder à Expression Builder en plaçant une page .aspx en mode conception et en accédant à la propriété Expressions via la feuille de propriétés.
Figure 6. Expression Builder
Notez que les expressions de liaison de ressources déclaratives ne sont pas limitées aux fichiers .aspx, .ascx et .master. Elles peuvent également être utilisées pour localiser les littéraux de type chaîne à partir d'un plan de site défini dans un fichier Web.sitemap. La figure 7 illustre le code XML du plan de site utilisé dans le site Web LitwareWebApp pour localiser les titres des liens illustrés dans le menu de navigation du site.
Utilisation de ressources locales
Un fichier de ressources locales contient les ressources d'un seul élément basé sur un fichier dans un site, par exemple une page, une page maître ou un contrôle utilisateur. Chaque fichier de ressources locales doit être correctement nommé et ajouté au dossier App_LocalResources pour être compilé par ASP.NET.
Un fichier de ressources locales doit être nommé conformément à l'élément basé sur les fichiers auquel il fournit ses ressources. Par exemple, le fichier de ressources locales contenant les ressources culturelles par défaut pour la page AddCustomer.aspx doit être nommé AddCustomer.aspx.resx. Le fichier de ressources locales contenant les ressources en français doit être nommé AddCustomer.aspx.fr.resx.
Une fois que vous avez ajouté les chaînes nommées à un fichier de ressources locales, vous pouvez y accéder à partir d'une page ou d'un contrôle utilisateur de trois façons différentes. Vous pouvez tout d'abord y accéder par programmation. Ensuite, vous pouvez procéder à une liaison déclarative avec une syntaxe explicite. Enfin, vous pouvez procéder à une liaison déclarative avec une syntaxe implicite. Examinons à présent chacune de ces approches.
Imaginons que vous ayez créé des fichiers de ressources locales afin de localiser toutes les légendes de contrôle illustrées sur la page AddCustomer.aspx. Pour localiser la légende affichée sur le bouton d'envoi de la page, vous pouvez créer une chaîne localisée nommée btnSubmit.Text. Une fois que vous avez ajouté cette chaîne nommée au fichier de ressources locales, vous pouvez y accéder via le code en appelant la méthode GetLocalResourceObject et en convertissant la valeur renvoyée en une chaîne :
'*** code inside AddCustomer.aspx.vb
btnSubmit.Text = _
Me.GetLocalResourceObject("btnSubmit.Text").ToString()
Ce code n'est pas aussi élégant que le code illustré précédemment pour accéder à une chaîne nommée à partir d'une ressource globale et utilisant une classe fortement typée. Les fichiers de ressources locales ne présentent pas de classes fortement typées associées ; vous ne pourrez donc pas tirer parti d'IntelliSense et vous devrez convertir explicitement la valeur renvoyée basée sur l'objet lors de l'appel de GetLocalResourceObject.
Si vous souhaitez utiliser une syntaxe de liaison déclarative explicite, cela fonctionne presque de la même façon que pour les ressources globales. La seule différence est que vous omettez le nom du fichier de ressources lors de l'utilisation de ressources locales :
<asp:Button ID="btnSubmit" runat="server" Text="<"%$ Resources:btnSubmit.Text %>" />
La syntaxe de liaison déclarative implicite est l'option la plus puissante. Vous commencez par ajouter un attribut spécial nommé meta:resourcekey à une balise de contrôle ou à une directive ASP.NET telle que Page, Master ou Control. Par exemple, si vous souhaitez utiliser la syntaxe de liaison déclarative implicite avec un contrôle Button dans un fichier .aspx, vous pouvez écrire sa balise comme suit :
<asp:Button ID="btnSubmit" runat="server" meta:resourcekey="btnSubmit" />
Une fois que vous avez ajouté l'attribut meta:resourcekey, la seule préoccupation consiste à s'assurer que le fichier de ressources locales contient des chaînes avec le nom approprié. Dans mon exemple, ASP.NET charge automatiquement la chaîne localisée nommée btnSubmit.Text et l'affecte à la propriété Text du contrôle nommé btnSubmit.
Le point important est que la liaison implicite est basée sur la création de chaînes dont les noms correspondent aux cibles définies par l'attribut meta:resourcekey plus le nom d'une propriété. Dans la mesure où meta:resourcekey dans cet exemple est collecté au niveau de btnSubmit, vous pouvez lier plusieurs autres valeurs de propriétés en plus de Text, en ajoutant d'autres chaînes nommées dans les fichiers de ressources locales, comme le montre la figure 8.
Figure 8. Ajout de chaînes nommées
Notez que Visual Studio 2005 offre une commande pratique appelée Générer une ressource locale dans le menu Outils lorsqu'une page, un contrôle utilisateur ou une page maître est ouvert dans l'éditeur de conception. Cette commande automatise la création d'un fichier de ressources locales pour la culture par défaut. Elle ajoute également des attributs meta:resourcekey dans la page et crée des valeurs de chaîne correspondantes dans le fichier de ressources locales, devant servir de cibles pour les entrées de l'attribut meta:resourcekey.
Enfin, notez qu'un nouveau composant ASP.NET 2.0 appelé contrôle Localize permet de localiser n'importe quel élément d'une page .aspx. Il offre une fonctionnalité de conception qui n'est pas offerte par sa classe de base, à savoir le contrôle Literal ; en particulier, le contrôle Localize permet l'édition du contenu statique lors de la conception, ce qui vous permet de voir une valeur par défaut lors du travail en mode conception de page.
Intégration de ressources dans un projet DLL
Je vais dévier un instant des sujets localisation et internationalisation afin d'étudier une nouvelle technique ASP.NET pour l'utilisation de ressources intégrées dans une DLL de bibliothèque de classes. Cette technique vous permet d'intégrer des ressources telles que des fichiers image, des feuilles de style CSS et des fichiers JavaScript dans une DLL et de les exposer via une URL sur le serveur Web d'hébergement.
Notez que cette technique nécessite l'utilisation d'une DLL de bibliothèque de classes qui cible les sites Web ASP.NET 2.0. La nouvelle fonctionnalité a été ajoutée par l'équipe ASP.NET pour offrir aux contrôles côté serveur un moyen plus efficace de distribuer les fichiers de ressources qui accompagnent leurs contrôles et composants WebPart personnalisés. Plutôt que d'avoir à distribuer les fichiers de ressources avec une DLL et à s'assurer qu'ils sont copiés dans un chemin accessible sur le serveur Web d'hébergement, les fichiers de ressources peuvent être distribués dans la DLL proprement dite et être exposés via des URL générées par ASP.NET lors de l'exécution.
Le site Web LitwareWebApp contient un projet de DLL de bibliothèque de classes nommé LitwareWebComponents, qui illustre cette technique. Dans ce projet, un fichier image nommé LitwareSlogan.png a été intégré en tant que ressource. Vous pouvez intégrer une ressource à un assembly en changeant la valeur Build Action to Embedded Resource du fichier, comme illustré figure 9.
Figure 9. Intégration d'une ressource
Pour permettre l'accès Web à un fichier de ressources intégré dans une DLL, vous devez ajouter un attribut de niveau assembly nommé WebResource. Lorsque vous ajoutez l'attribut WebResource, vous devez inclure le nom qualifié du fichier de ressources, ainsi que son type MIME. Dans un projet DLL de bibliothèque de classes Visual Basic®, le nom du fichier de ressources qualifié inclut le nom du projet.
'*** inside AssemblyInfo.vb
Imports System.Web.UI
<Assembly: WebResource=""( _=""
"LitwareWebComponents.LitwareSlogan.png", "image/png")>
L'attribut WebResource est ce qui vous permet de fournir au runtime ASP.NET les métadonnées dont il a besoin pour extraire le fichier de ressources de la DLL avec une URL pouvant être générée lors de l'exécution. Pour générer l'URL vers le fichier de ressources à partir du code dans un contrôle côté serveur, vous appelez une méthode nommée GetWebResourceUrl, comme illustré figure 10.
Voici ce qui se passe en coulisses pour que cette technique fonctionne. Un appel de GetWebResourceUrl génère une URL pointant vers un gestionnaire HTTP intégré nommé WebResource.axd. L'URL générée dynamiquement inclut également une chaîne de requête qui identifie le nom de la DLL cible et le fichier de ressources intégré. Le runtime ASP.NET répond aux requêtes de WebResource.axd en chargeant une classe HttpHandler personnalisée nommée AssemblyResourceLoader.
Lorsque la classe AssemblyResourceLoader est appelée pour charger un fichier de ressources à partir d'une DLL, elle lit les métadonnées fournies par l'attribut WebResource. La classe AssemblyResourceLoader a été implémentée afin d'extraire le fichier de ressources de requête de l'image de la DLL et de le renvoyer à l'appelant. La classe AssemblyResourceLoader offre même un algorithme de mise en cache, lequel peut réutiliser le même fichier de ressources pour plusieurs demandes après son chargement en mémoire sur l'hôte du serveur Web front-end.
Affichage des images localisées
Même si l'utilisation de fichiers de ressources intégrés et de l'attribut WebResource est puissante, il existe quelques limitations importantes. Tout d'abord, vous pouvez utiliser cette technique seulement dans un projet DLL ciblé pour les sites Web ASP.NET 2.0. Vous ne pouvez pas l'utiliser directement dans un site Web ASP.NET 2.0. Ensuite, cette technique ne prend en charge aucune forme de localisation. Vous devez recourir à une approche différente si votre site Web comporte des fichiers de ressources tels que des images et des feuilles de style localisées.
Le site Web LitwareWebApp affiche une image graphique nommée LitwareSlogan.png. Le site a été conçu pour afficher une version différente de l'image selon que l'utilisateur actuel préfère l'anglais ou le français. Si ASP.NET 2.0 ne prend pas directement en charge la localisation des fichiers image, il ne nécessite pas trop de code pour obtenir l'effet souhaité.
Vous pouvez commencer par ajouter les versions localisées d'un fichier image aux versions localisées d'un fichier de ressources globales. Par exemple, la version en anglais de LitwareSlogan.png a été ajoutée au fichier de ressources globales nommé Litware.resx, tandis que la version en français de LitwareSlogan.fr.png a été ajoutée à Litware.fr.resx. Les ressources des deux fichiers de ressources portent le même nom, à savoir LitwareSlogan.
Lorsque vous avez des versions localisées du fichier image dans différentes versions localisées d'un fichier de ressources globales, vous pouvez les charger de manière conditionnelle en fonction de la préférence de langue de l'utilisateur, en utilisant le fichier de gestionnaire personnalisé nommé LitwareSlogan.ashx, comme le montre la figure 11.
La classe de gestionnaire personnalisé définie dans LitwareSlogan.ashx initialise le paramètre CurrentUICulture actuel du thread avant d'extraire le fichier image du fichier de ressources globales, en utilisant une logique semblable à celle que vous avez vue précédemment dans la méthode InitializeCulture. Notez que pour charger un fichier de ressources approprié, vous devez initialiser la propriété CurrentUICulture actuelle du thread, mais il n'est pas nécessaire d'initialiser la propriété CurrentCulture.
Une fois que ce gestionnaire personnalisé a correctement initialisé le paramètre CurrentUICulture, il peut accéder au fichier image via la classe de ressources fortement typée pour Litware.resx. Il suffit ensuite d'écrire les éléments du fichier image dans le flux de réponse HTTP. La toute dernière étape pour afficher l'image localisée consiste à affecter l'URL LitwareSlogan.ashx à la propriété ImageUrl d'un contrôle Image sur n'importe quelle page du site.
Conclusion
ASP.NET 2.0 facilite l'internationalisation des sites Web et des ressources. Il est trivial d'initialiser les paramètres culturel pour les pages d'un site Web en examinant les en-têtes HTTP envoyés par le navigateur. Il est en outre facile de concevoir un schéma plus élaboré permettant aux utilisateurs de personnaliser leur environnement en configurant leurs préférences linguistiques.
Envoyez vos questions et commentaires à Ted à l'adresse instinct@microsoft.com.
Ted Pattison, auteur et formateur, a récemment fondé Gorilla Training, une entreprise dédiée à la formation des développeurs aux technologies SharePoint. Ted écrit également un ouvrage intitulé Inside Windows SharePoint Services 3.0 pour Microsoft Press.
Numéro d'août 2006 de MSDN Magazine (en anglais).