Présentation de la localisation d’ASP.NET AJAX

Article
07/13/2023

La localisation est le processus de conception et d’intégration de la prise en charge d’un langage et d’une culture spécifiques dans une application ou un composant d’application. La plateforme Microsoft ASP.NET offre une prise en charge étendue de la localisation pour les applications ASP.NET standard en intégrant le modèle de localisation .NET standard ; Microsoft AJAX Framework utilise le modèle intégré pour prendre en charge les différents scénarios dans lesquels la localisation peut être effectuée.

Introduction

La technologie ASP.NET de Microsoft apporte un modèle de programmation orienté objet et piloté par les événements et l’associe aux avantages du code compilé. Toutefois, son modèle de traitement côté serveur présente plusieurs inconvénients inhérents à la technologie, dont beaucoup peuvent être traités par les nouvelles fonctionnalités incluses dans l’espace de noms System.Web.Extensions, qui encapsule les services Microsoft AJAX dans .NET Framework 3.5. Ces extensions permettent de nombreuses fonctionnalités client enrichies, précédemment disponibles dans le cadre des extensions AJAX ASP.NET 2.0, mais qui font désormais partie de la bibliothèque de classes de base du framework. Les contrôles et les fonctionnalités de cet espace de noms incluent le rendu partiel des pages sans nécessiter une actualisation complète de la page, la possibilité d’accéder aux services web via un script client (y compris l’API de profilage ASP.NET) et une API côté client étendue conçue pour miroir la plupart des schémas de contrôle vus dans l’ensemble de contrôles côté serveur ASP.NET.

Ce livre blanc examine les fonctionnalités de localisation présentes dans Microsoft AJAX Framework et la bibliothèque de scripts Microsoft AJAX, dans le contexte des besoins de l’entreprise en matière de prise en charge de la localisation et examine la prise en charge déjà intégrée de la localisation dans les applications web fournies par le .NET Framework. La bibliothèque de scripts Microsoft AJAX utilise le format de fichier .resx déjà utilisé par les applications .NET, qui fournit une prise en charge intégrée de l’IDE et un type de ressource partageable.

Ce livre blanc est basé sur la version bêta 2 de Microsoft Visual Studio 2008. Ce livre blanc suppose également que vous travaillerez avec Visual Studio 2008, et non avec Visual Web Developer Express, et que vous fournirez des procédures pas à pas en fonction de l’interface utilisateur de Visual Studio. Certains exemples de code utilisent des modèles de projet qui peuvent être indisponibles dans Visual Web Developer Express.

Le besoin de localisation

En particulier pour les développeurs d’applications d’entreprise et les développeurs de composants, la possibilité de créer des outils capables de prendre conscience des différences entre les cultures et les langages est devenue de plus en plus nécessaire. La conception de composants avec la possibilité de s’adapter aux paramètres régionaux du client augmente la productivité des développeurs et réduit la quantité de travail nécessaire à l’adaptation d’un composant pour fonctionner globalement.

La localisation est le processus de conception et d’intégration de la prise en charge d’un langage et d’une culture spécifiques dans une application ou un composant d’application. La plateforme Microsoft ASP.NET offre une prise en charge étendue de la localisation pour les applications ASP.NET standard en intégrant le modèle de localisation .NET standard ; Microsoft AJAX Framework utilise le modèle intégré pour prendre en charge les différents scénarios dans lesquels la localisation peut être effectuée. Avec Microsoft AJAX Framework, les scripts peuvent être localisés en étant déployés dans des assemblys satellites ou en utilisant une structure de système de fichiers statique.

Incorporation de scripts avec des assemblys satellites

Conformément à la stratégie de localisation .NET Framework standard, les ressources peuvent être incluses dans des assemblys satellites. Les assemblys satellites offrent plusieurs avantages par rapport à l’inclusion de ressources traditionnelles dans les fichiers binaires : toute localisation donnée peut être mise à jour sans mettre à jour l’image plus grande, des localisations supplémentaires peuvent être déployées simplement en installant des assemblys satellites dans le dossier du projet, et les assemblys satellites peuvent être déployés sans provoquer de rechargement de l’assembly de projet main. En particulier dans les projets ASP.NET, cela est bénéfique, car il peut réduire considérablement la quantité de ressources système utilisées par les mises à jour incrémentielles et perturber au minimum l’utilisation du site web de production.

Les scripts sont incorporés dans des assemblys en les incluant dans des fichiers .resx managés (ou .resources compilés), qui sont inclus dans l’assembly au moment de la compilation. Leurs ressources sont ensuite mises à la disposition de l’application de script via le code généré par le runtime AJAX, via des attributs au niveau de l’assembly

Conventions d’affectation de noms pour les fichiers de script incorporés

La gestion des scripts Microsoft AJAX Framework prend en charge diverses options d’utilisation dans le déploiement et le test de scripts, et des instructions sont fournies pour faciliter ces options.

Pour faciliter le débogage :

Les scripts de mise en production ne doivent pas inclure le .debug qualificateur dans le nom de fichier. Les scripts conçus pour le débogage doivent inclure .debug dans le nom de fichier.

Pour faciliter la localisation :

Les scripts de culture neutre ne doivent pas inclure d’identificateur de culture dans le nom du fichier. Pour les scripts qui contiennent des ressources localisées, le code de langue ISO doit être spécifié dans le nom de fichier. Par exemple, es-CO signifie Espagnol, Columbia.

Le tableau suivant récapitule les conventions d’affectation de noms de fichiers avec des exemples :

Nom de fichier	Signification
Script.js	Script indépendant de la culture de version.
Script.debug.js	Un script indépendant de la culture de la version de débogage.
Script.en-US.js	Une version de mise en production en anglais, États-Unis script.
Script.debug.es-CO.js	Un script Debug-version spanish, Columbia.

Procédure pas à pas : Créer un script incorporé localisé

Remarque : cette procédure pas à pas nécessite l’utilisation de Visual Studio 2008, car Visual Web Developer Express n’inclut pas de modèle de projet pour les projets de bibliothèque de classes.

Créez un projet de site web avec ASP.NET extensions AJAX intégrées. Créez un autre projet, un projet bibliothèque de classes, dans la solution appelée LocalizingResources.
Ajoutez un fichier Jscript appelé VerifyDeletion.js au projet LocalizingResources, ainsi que des fichiers de ressources .resx appelés DeletionResources.resx et DeletionResources.es.resx. Le premier contiendra des ressources indépendantes de la culture; ce dernier contiendra des ressources en espagnol.
Ajoutez le code suivant à VerifyDeletion.js :

function VerifyDeletion(fileName)
{
 if (confirm(Message.VerifyDelete.replace(/FILENAME/, fileName)))
 {
 Delete(fileName);
 return true;
 }
 return false;
}
function Delete(fileName)
{
 alert (Message.Deleted.replace(/FILENAME/, fileName));
}

Pour ceux qui ne connaissent pas la syntaxe JavaScript Regex, le texte dans des barres obliques uniques (dans l’exemple précédent, /FILENAME/ est un exemple) désigne un objet RegExp. MSDN Library contient une référence JavaScript complète, et des ressources sur les objets natifs JavaScript sont disponibles en ligne.

Ajoutez les chaînes de ressources suivantes à SuppressionResources.resx :

VerifyDelete : Êtes-vous sûr de vouloir supprimer FILENAME ?

Supprimé : FILENAME a été supprimé.
Ajoutez les chaînes de ressources suivantes à DeletionResources.es.resx :

VerifyDelete: Est seguro que desee quitar FILENAME?

Supprimé : FILENAME se ha quitado.
Ajoutez les lignes de code suivantes au fichier AssemblyInfo :

[assembly: System.Web.UI.WebResource("LocalizingResources.VerifyDeletion.js",
 "text/javascript")]
[assembly: System.Web.UI.ScriptResource("LocalizingResources.VerifyDeletion.js",
 "LocalizingResources.DeletionResources", "Message")]

Ajoutez des références à System.Web et System.Web.Extensions au projet LocalizingResources.
Ajoutez une référence au projet LocalizingResources à partir du projet site web.
Dans default.aspx, sous le projet Site web, mettez à jour le contrôle ScriptManager avec le balisage supplémentaire suivant :

<asp:ScriptManager ID="ScriptManager1" runat="server" EnableScriptLocalization="true">
 <Scripts>
 <asp:ScriptReference Assembly="LocalizingResources" Name="LocalizingResources.VerifyDeletion.js"/>
 </Scripts>
</asp:ScriptManager>

Dans default.aspx, n’importe où sur la page, incluez ce balisage :

<asp:Button ID="btnDelete" runat="Server" OnClientClick="VerifyDeletion('a.txt');" Text="Delete" />

Appuyez sur F5. Si vous y êtes invité, activez le débogage. Lorsque la page est chargée, appuyez sur le bouton Supprimer. Notez que vous êtes invité en anglais (sauf si votre ordinateur est configuré pour préférer les ressources en espagnol par défaut) pour confirmation.
Fermez la fenêtre du navigateur et revenez à default.aspx. Dans la @Page directive d’en-tête, remplacez auto pour Culture et UICulture par es-ES. Appuyez de nouveau sur F5 pour relancer l’application web dans le navigateur. Cette fois, notez que vous êtes invité à supprimer le fichier en espagnol :

(Cliquez pour afficher l’image en taille réelle)

Notez qu’il existe plusieurs variantes pour cette procédure pas à pas. Par instance, les scripts peuvent être inscrits avec le contrôle ScriptManager par programmation pendant le chargement de la page.

Inclusion d’une structure de fichier de script statique

Lorsque vous utilisez des fichiers de script statiques pour le déploiement, vous perdez certains des avantages de l’utilisation du schéma de localisation .NET inhérent. La plus visible est que vous perdez le type automatique généré à partir de l’inclusion des fichiers de ressources de script ; dans la procédure pas à pas ci-dessus, par exemple, les ressources ont été exposées par un type généré automatiquement appelé Message à partir du contrôle ScriptManager.

Toutefois, l’utilisation d’une structure de fichier de script statique présente certains avantages. Mises à jour peut être effectué sans recompiler et redéployer des assemblys satellites, et l’utilisation d’une structure de fichiers statique peut également être effectuée pour remplacer le script incorporé, afin d’intégrer une fonctionnalité mineure qui n’a peut-être pas été fournie avec un composant.

Microsoft recommande d’éviter un problème de gestion de version en générant automatiquement vos ressources de script pendant la compilation du projet. Lors de la maintenance d’une base de code de script étendue, il peut devenir de plus en plus difficile de s’assurer que les modifications de code sont reflétées dans chaque script localisé. En guise d’alternative, vous pouvez simplement conserver un script logique et plusieurs scripts de localisation, en fusionnant les fichiers lors de la génération du projet.

Étant donné qu’il n’y a pas de ressources à inclure de manière déclarative, les fichiers de script statique doivent être référencés soit en ajoutant <asp:ScriptElement> des éléments en tant qu’enfant de la <Scripts> balise du contrôle ScriptManager, soit en ajoutant ScriptReference par programmation des objets à la Scripts propriété du ScriptManager contrôle sur la page au moment de l’exécution.

ScriptManager et son rôle dans la localisation

ScriptManager active plusieurs comportements automatiques pour les applications localisées :

Il localise automatiquement les fichiers de script en fonction des paramètres et des conventions d’affectation de noms ; pour instance, il charge les scripts activés pour le débogage en mode débogage et charge les scripts localisés en fonction de la sélection de l’interface utilisateur du navigateur.
Il permet de définir des cultures, y compris des cultures personnalisées.
Il permet la compression des fichiers de script via HTTP.
Il met en cache les scripts pour gérer efficacement de nombreuses demandes.
Il ajoute une couche d’indirection aux scripts en les canalisant via une URL chiffrée.

Les références de script peuvent être ajoutées au contrôle ScriptManager par programmation ou par balisage déclaratif. Le balisage déclaratif est particulièrement utile lors de l’utilisation de scripts incorporés dans des assemblys autres que le projet de site web lui-même, car le nom du script ne changera probablement pas à mesure que les révisions sont envoyées.

Résumé

À mesure que les applications web se développent pour atteindre un public plus large, la nécessité d’être en mesure d’atteindre des cultures et des communautés plus larges devient au cœur d’un modèle d’entreprise; Les applications web de commerce électronique doivent être en mesure de traiter les devises étrangères, les systèmes de gestion de contenu doivent être en mesure de présenter non seulement leur contenu, mais également leurs indicateurs de navigation et leurs champs de formulaire dans d’autres langues, et les entreprises doivent savoir que ce besoin est accessible.

Le .NET Framework prend intrinsèquement en charge une infrastructure de localisation riche, utilisant des assemblys satellites et des fichiers de ressources XML (.resx) pour présenter un moyen uniforme de rechercher des chaînes de ressources et des images. Les ASP.NET extensions AJAX, y compris Microsoft AJAX Framework et la bibliothèque de scripts Microsoft AJAX, prennent en charge ce modèle de programmation dans le code côté client, ce qui permet de faciliter les recherches de chaînes de ressources. Les assemblys satellites prennent en charge l’inclusion automatique de ressources de script (fichiers .js réels) via ScriptResource.axd tant que les noms de fichiers suivent un schéma de nommage donné. Grâce à cette prise en charge, les extensions AJAX ASP.NET simplifient la localisation des scripts et la globalisation des applications.

Bio

Scott Cate travaille avec les technologies Web Microsoft depuis 1997 et est président de myKB.com (www.myKB.com) où il se spécialise dans la rédaction d’applications ASP.NET basées sur des solutions logicielles de base de connaissances. Scott peut être contacté par e-mail à l’adresse scott.cate@myKB.com ou son blog à ScottCate.com

Précédent Suivant

Partager via