На текущата ми проект, някои от потребителите ще пътуват по света и когато те пристигнат в различни дестинации, Използвайте каквато и машина е удобен по време. Тези машини, гости ще работи с Windows и инсталирани и конфигурирани за местни локал. (Просто осъзнах, че на гости машини не могат да имат правилния език вързоп… вероятно няма да, Всъщност… Аз съм че един за сега паркинг).
SharePoint трябва да предостави механизъм, чрез която потребителят може да изберете предпочитания от тях език и след това са МЪХА чест този език независимо как потребителят влиза Мос. С други думи, незачитане каквото браузъра казва IIS/Мос и вместо това потърсете този предпочитан език и го използват.
Ние ще разследва два подхода:
- HTTP манипулатора: Персонализирани HTTP манипулатор, инсталирани на IIS ще потърсите Мос профила на потребителя, разбера предпочитан език и след това да превключвате HTTP заглавката около, ако е необходимо, преди да премине контрола на Мос.
- Global.asax: Променят global.asax да направи същото нещо. Ние може да промени нещо друго, но идеята е, че ние намери някое място, където можете да поставите нашите превключване на локал логика.
Друг усложняващ фактор е, че ние трябва да поддръжка 60k потребители, за 1,000 на които могат да бъдат едновременно достъп до Мос в връх натоварване.
HTTP манипулатора изглежда доста драстични, но вероятно най-доброто място да поставите кода, тъй като тя е на IIS ниво и всезнаещ. Това е добра една точка на работа.
Ние сме наведе се към global.asax тип подход, главно, защото вярваме, че ще имаме повече опции за кеширане на данни в този момент.
Аз ще бъда блог повече по този въпрос, като научи повече.
Ако знаете нещо за това, please post a comment 🙂
</край>
Следвайте ме на Twitter в http://www.twitter.com/pagalvin
Аз имам не проверка този така че аз не съм сигурен дали тя работи.
На страницата класа е InitializeCulture() метод, който може да се обори. Ако направите това в кода зад вашия потребителски образец, Можете да направите нещо по подобие на:
защитените замени анулира InitializeCulture()
{
// замени виртуален метод InitializeCulture() за да проверите, ако профил съдържа настройка за език потребителят
низ UserCulture = GetCultureFromUserProfile();
Ако ( UserCulture != "")
{
// има потребителски език настройка в профила: към него
Thread.CurrentThread.CurrentUICulture = нов CultureInfo(UserCulture);
Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture(UserCulture);
}
}
Очевидно може да се изгради някои кеширане в прилагането на този метод.
Източник: HTTP://quickstarts.asp.net/QuickStartv20/util/srcview.aspx?Path=~/aspnet/samples/localization/LocalizePers.SRC&файла = LocalizePers_cs\LocalizePers_cs.aspx&Lang = C % 23 източник
Аз съм мислене HTTP манипулатора със следните поток:
1. Постъпи заявка, Проверете бисквитки за сесия бисквитка за предпочитания език (сесия бисквитките изтичат, когато браузърът е затворен)
2. Проверете дали искането е за ASPX страница, Ако не, пропуснете заявка
3. Ако бисквитката съществува, Задайте език заглавието на зададената стойност. Сте готови!
4. Няма бисквитка, Вземете на идентификационните данни за удостоверяване и гледам потребителя в SPS, намери предпочитания език
5. Бисквитка заглавката и HTTP заглавката,, език. Съставено.
Първата заявка за страница на APX ще има режийни на SPS lookup, но всяко искане от този момент нататък с има няма заявки, така че ще бъде родния скорост. Няма нужда от кеша на сесия или някакви други режийни като използвате сесийни твърде. След като на браузъра е затворен, сесийната бисквитка изчезва. Ако потребителят промени предпочитанията си езици в SPS те просто трябва да затворите и отново отворите браузъра за да влязат в сила.
всъщност не е манипулаторът на http на iis ниво…Тя е на ниво приложение (ISAPI филтри са на нивото на IIS)…ще бъдете внимателни, bc SP има своя собствена манипулатор…така че не забравяйте да го тествате…Аз съм правил това преди, но са имали някои конфликт с манипулатора на SP.
Ще съм по-склонен да използвате HTTPHandler, единствената причина е, че не обичам докосване на SharePoint файлове. Плюс това е лесно да се създаде SharePoint решение за разполагане на HttHandler ( и използване на SPWebConfig API за модифициране на web.config). Като натоварването на потребителя ти правя, Предполагам имате доста голяма ферма, наистина не искам да отида modifiying файлове на всеки сървър.
Разполагането на global.asa файл чрез решение е лоша идея, Ако ви се прибере, оригиналния файл е отишъл …
Също така като способността за бързо отстраняване на решение може да е добра идея, в случай, че нещата се объркат с ИД на манипулатор.