Sur mon projet en cours, certains utilisateurs seront rendra dans le monde entier, et lorsqu'ils arrivent à des destinations différentes, utiliser quelque machine est maniable dans le temps. Ces ordinateurs invités s'exécutera Windows et installé et configuré pour les paramètres régionaux locaux. (J'ai viens de réaliser que les ordinateurs invités n'ont ne peut-être pas les bonne langue emaballages… ne sera probablement pas, En fait… Je suis celui-là pour l'instant de stationnement).
SharePoint a besoin de concevoir un mécanisme par lequel l'utilisateur peut choisir la langue de leur choix et ont ensuite MOSS honorer cette langue, quelle que soit la façon dont l'utilisateur accède à MOSS. En d'autres termes, ne pas tenir compte de tout ce que le navigateur raconte IIS/MOSS et plutôt chercher cette langue préférée et l'utiliser.
Nous allons étudier deux approches:
- Gestionnaire HTTP: Voir le profil de l'utilisateur MOSS va rechercher un gestionnaire HTTP personnalisé installé sur IIS, comprendre la langue préférée, puis passer l'en-tête HTTP autour au besoin avant de passer le contrôle à MOSS.
- global.asax: Modifier global.asax afin de faire la même chose. Nous pouvons modifier quelque chose d'autre, mais l'idée est que nous trouver un endroit où nous pouvons insérer notre logique de commutation locale.
L'autre facteur de complication, c'est que nous devons soutien 60k utilisateurs, sur 1,000 de qui peut être simultanément accès à MOSS au pic de charge.
Le gestionnaire HTTP semble assez drastique, mais peut-être le meilleur endroit pour mettre le code, puisque c'est au niveau d'IIS et Omniscient. C'est un bon point unique de travail.
Nous sommes penché vers une approche de type global.asax, principalement parce que nous croyons que nous aurons plus d'options pour la mise en cache des données à ce moment-là.
Je serai blogging plus à ce sujet car j'en savoir plus.
Si vous avez connaissez rien à ce sujet, s'il vous plaît poster un commentaire 🙂
</fin>
Me suivre sur Twitter à http://www.twitter.com/pagalvin
Je n'ai pas testé donc je ne sais pas si ça marche.
La classe de Page a un InitializeCulture() méthode qui peut être substituée. Si vous faites cela dans le code-behind de votre gabarit personnalisé, vous pourriez faire quelque chose dans le sens de:
Protected Overrides Sub InitializeCulture()
{
// substituer la méthode virtuelle InitializeCulture() pour vérifier si le profil contient un paramètre de langue de l'utilisateur
String UserCulture = GetCultureFromUserProfile();
Si ( UserCulture != "")
{
// Il y a un paramètre de langue de l'utilisateur dans le profil: basculer vers lui
Thread.CurrentThread.CurrentUICulture = gcnew CultureInfo(UserCulture);
Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture(UserCulture);
}
}
Évidemment, vous pouvez créer une mise en cache dans l'implémentation de cette méthode.
Source: http://quickstarts.asp.net/QuickStartv20/util/srcview.aspx?Path=~/ASPNET/Samples/localization/LocalizePers.SRC&fichier = LocalizePers_cs\LocalizePers_cs.aspx&lang = C % 23 source
Je pense gestionnaire HTTP avec le flux suivant:
1. Requête arrive, vérifier les cookies un cookie de session pour la langue de préférence (les cookies de session expirent lorsque le navigateur est fermé)
2. Vérifier si la demande est pour une page ASPX, dans le cas contraire, ignorer la demande
3. Si le cookie existe, la valeur de l'en-tête de la langue à la valeur spécifiée. Vous avez terminé!
4. Aucun cookie, prendre les informations d'identification d'authentification et de Rechercher l'utilisateur dans SPS, trouver la langue de préférence
5. Définissez l'en-tête cookie et en-tête HTTP du language. Fait.
Première demande de page APX aura frais généraux de la fonction lookup SPS mais chaque demande alors avec aucune recherches donc sera vitesse native. Pas besoin de cache de session ou tout autres frais généraux en utilisant un cookie de session aussi. Une fois que le navigateur est fermé, le cookie de session s'en va. Si l'utilisateur modifie leur préférence langues dans SPS ils ont juste besoin de fermer et rouvrir le navigateur pour qu'il prenne effet.
le gestionnaire http n'est pas réellement au niveau d'iis…C'est au niveau de l'application (Les filtres ISAPI sont au niveau IIS)…Je serais prudent que BC SP possède son propre gestionnaire…donc n'oubliez pas de le tester…J'ai fait avant mais ont eu quelques conflits avec le gestionnaire de SP.
Je serais plus enclin à utiliser un HTTPHandler, la seule raison est que je n'aime pas toucher les fichiers SharePoint. Plus il est facile de créer une solution SharePoint pour déployer un HttHandler ( et l'utilisation de l'API SPWebConfig pour modifier le fichier web.config). Ayant la charge de l'utilisateur, vous faites, J'imagine que vous avez une ferme assez importante, vous ne voulez vraiment pas aller modifier les fichiers sur chaque serveur.
Déployer le fichier global.asa via une solution est une mauvaise idée, Si vous se rétracter, votre fichier d'origine a disparu …
Ayant la possibilité de revenir rapidement sur la solution pourrait être une bonne idée, dans le cas où les choses vont mal avec la perf du gestionnaire.