На мојот тековниот проект, некои од корисниците ќе патува низ светот и кога ќе пристигнат на различни дестинации, use whatever machine is handy at the time. Those guest machines will be running Windows and installed and configured for the local locale. (Јас сум само сфатив дека гостинот машини не може да ги имаат право јазични пакети… веројатно нема, всушност… Јас сум паркирал дека една сега за сега).
SharePoint needs to provide a mechanism whereby the user can pick their preferred language and then have MOSS honor that language regardless of how the user accesses MOSS. In other words, disregard whatever the browser tells IIS/MOSS and instead look up that preferred language and use it.
Ние ќе се испита два пристапа:
- HTTP Хендлер: А обичај HTTP управувачот инсталиран на IIS ќе се погледне нагоре Мос профилот на корисникот, дознаам склопот на јазикот, а потоа преминете на HTTP заглавието околу колку што е потребно пред да го одмине контрола на Мос.
- Global.asax: Modify global.asax to do the same thing. We may modify something else, but the idea is that we find some place where we can insert our locale-switching logic.
Од друга Комплициран фактор е тоа што ние треба да се поддржи 60k корисници, за 1,000 од кои може да биде истовремено пристапуваат Мос на врвно оптоварување.
На управувачот HTTP чини прилично драстични, but possibly the best place to put the code since it’s at the IIS level and all-knowing. It’s a good single point of work.
Ние сме потпирајќи се кон Global.asax тип пристап, главно затоа што ние веруваме дека ќе имаме повеќе опции за кеширање на податоци во тој момент.
Јас ќе бидам блогирањето повеќе на оваа тема, како јас дознаете повеќе.
Ако имате знае ништо за ова, ве молиме објавете коментар
</крајот>
Да се претплатите на мојот блог.
Следете ме на Twitter во http://www.twitter.com/pagalvin
Јас не се тестираат ова, па јас не сум сигурен дали таа работи.
Страна класа има InitializeCulture() метод со кој може да се прескокнат. Ако го направите ова во кодот зад од вашите сопствени masterpage, можете да го направите нешто по должината на линиите на:
заштитени замени празнина InitializeCulture()
{
// избегне виртуелен метод InitializeCulture() да проверите дали ОК содржи корисникот јазикот
низа UserCulture = GetCultureFromUserProfile();
ако ( UserCulture != "")
{
// има корисникот јазикот амбиент во профилот: се префрлат на неа
Thread.CurrentThread.CurrentUICulture = new CultureInfo(UserCulture);
Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture(UserCulture);
}
}
Очигледно може да се изгради некои кеширање во спроведувањето на овој метод.
Извор: HTTP://quickstarts.asp.net/QuickStartv20/util/srcview.aspx?патека = ~ / aspnet / примероци / локализација / LocalizePers.src&file = LocalizePers_cs\LocalizePers_cs.aspx&lang = C% 23 изворните
Јас сум размислување за HTTP управувачот со следните проток:
1. Барањето доаѓа во, провери колачиња за куки на сесијата за јазикот предност (сесија колачиња истекува кога прелистувачот е затворена)
2. Провери дали барањето е за aspx страница, ако не, прескокнете барање
3. Ако колаче постои, поставите на јазикот насловот до вредноста определена. Ќе се направи!
4. Нема колаче, преземе за проверка на акредитивен и да бараат на корисникот во СПС, најде јазик Преферирам
5. Постави колаче насловот и HTTP јазик насловот. Признаена.
Првиот APX страница барање ќе има над глава на СПС пребарување, но секое барање од тогаш па натаму со немаат пребарувања, па ќе биде мајчин брзина. Нема потреба за сесија кеш или било кој друг над глава со помош на куки на сесијата премногу. Еднаш на пребарувачот е затворена, на куки на сесијата си оди. Ако корисникот го менува нивните јазици предност во СПС тие само треба да се затвори и повторно да го отворите прелистувачот за истиот да стапи на сила.
всушност на управувачот HTTP не е на ниво IIS…тоа е во примената ниво (ISAPI Филтри се на ниво на IIS)…јас би се биде внимателен п.н.е. СП има свој управувачот…па не заборавајте да го пробате…Сум го направи порано, но имале некои конфликт со управувачот СП.
Јас ќе се посклони да се користи HTTPHandler, единствената причина е тоа што не ми се допаѓа допирање на SharePoint датотеки. Плус тоа е лесно да се создаде решение SharePoint да распореди HttHandler ( и да го користите SPWebConfig API е за менување на web.config). Тоа што на корисникот оптоварување што го правите, Јас би се замисли имаш доста голем фарма, што навистина не сакаат да одат modifiying датотеки на секој сервер.
Имплементирање на датотеката global.asa преку решение е лоша идеја, ако го прибирам, вашите оригиналната датотека е исчезнат …
Исто така има способност да се повлече решение брзо може да биде добра идеја, во случај нешто да тргне наопаку со перфорации на управувачот.