На маім бягучым праекце, некаторыя з карыстальнікаў будзе падарожнічаць па ўсім свеце, і калі яны прыходзяць да розных напрамках, 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 будзе шукаць MOSS профілі карыстальніка, высветліць патрэбны мову, а затым уключыце HTTP загалоўка вакол па меры неабходнасці перад перадачай кіравання MOSS.
- 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 падыход тыпу, галоўным чынам, таму што мы лічым, што мы будзем мець больш варыянтаў для кэшавання дадзеных у гэтай кропцы.
Я буду больш блогаў на гэтую тэму, як я магу даведацца больш.
Калі вы ведаеце што-небудзь пра гэта, please post a comment 🙂
</канец>
Выконвайце за мной на Twitter у http://www.twitter.com/pagalvin
Я не правяраў гэта так, я не ўпэўнены, калі гэта працуе.
Старонка клас мае InitializeCulture() метад, які можа быць зменены. Калі вы робіце гэта ў код вашага карыстацкага MasterPage, вы можаце зрабіць нешта накшталт:
абаронены 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 = ~ / САШ / ўзоры / лакалізацыі / LocalizePers.src&Выява = LocalizePers_cs\LocalizePers_cs.aspx&LANG = C% 23 зыходны
Я думаю HTTP апрацоўшчык з наступным патокам:
1. Прыходзіць запыт, праверыць печыва для сесійныя печыва для моўных пераваг (сесійныя печыва мінае пры закрыцці браўзэра)
2. Пераканайцеся, што запыт на ASPX старонкі, калі не, прапусціць запыце
3. Калі файл існуе, ўстанавіць мову загалоўка са значэннем, названым. Вы зрабілі!
4. Няма печыва, прыняць аўтэнтыфікацыю уліковых дадзеных і пошуку карыстальнікаў у СПС, Знайсці моўныя перавагі
5. Ўсталяваць ўдару галавой печыва і HTTP загалоўка мовы. Зроблены.
Першая старонка запыту APX будзе мець накладныя выдаткі на пошук SPS але кожны запыт з тых часоў з не маюць пошукаў так будзе роднай хуткасці. Няма неабходнасці ў кэшы сесіі або любыя іншыя накладныя выдаткі, выкарыстоўваючы сесійныя печыва занадта. Пасля закрыцця браўзэра, печыва сесіі сыходзіць. Калі карыстач змяняе іх мовы перавагу ў SPS яны проста павінны зачыніць і зноў адкрыць браўзэр для таго, каб уступіць у сілу.
на самай справе апрацоўшчык HTTP не на ўзроўні IIS…гэта на ўзроўні прыкладанняў (Фільтры ISAPI знаходзяцца на ўзроўні IIS)…Я быў бы асцярожны BC SP мае свой уласны апрацоўшчык…так што не забудзьцеся праверыць яго…Я рабіў гэта і раней, але былі некаторыя канфлікты з апрацоўшчыкам SP.
Я быў бы больш схільны выкарыстоўваць HTTPHandler, Адзіная прычына ў тым, што мне не падабаюцца дакранання да SharePoint файлы. Акрамя таго, ён лёгка ствараць рашэнні SharePoint для разгортвання HttHandler ( і выкарыстоўваць SPWebConfig API па змене web.config). Маючы карыстацкую нагрузку вы робіце, Я выказаў здагадку бы, што ў вас ёсць значныя фермы, Вы сапраўды не хочаце ісці не змяняць файлы на кожным серверы.
Разгортванне файла global.asa праз рашэнне гэта дрэнная ідэя, Калі вы ўцягваеце яе, зыходны файл больш няма …
Акрамя таго, маючы магчымасць адмовіцца рашэнне хутка можа быць добрай ідэяй, ў выпадку, калі нешта пойдзе не так з перфарацыя апрацоўшчыка.