Sa aking kasalukuyang proyekto, ang ilan sa mga gumagamit ay maglakbay sa buong mundo at kapag dumating sila sa iba't ibang destinasyon, use whatever machine is handy at the time. Those guest machines will be running Windows and installed and configured for the local locale. (Lamang ko na natanto na ang mga guest machine ay hindi maaaring magkaroon ng karapatan pack wika… marahil ay hindi, sa katunayan… Ako paradahan na ang isa para sa ngayon).
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.
Kami ay pagpunta sa imbestigahan dalawang approach:
- HTTP Handler: Ang isang pasadyang handler HTTP naka-install sa IIS magiging hitsura up Moss profile ng gumagamit, maisip kung ang nais na wika at pagkatapos ay lumipat sa HTTP header sa paligid tulad ng kinakailangan bago pagpasa kontrol sa 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.
Ang iba pang mga complicating kadahilanan ay na kailangan namin upang suportahan ang mga gumagamit 60k, tungkol sa 1,000 ng na maaaring sabay-sabay-access ng Moss sa peak load.
Ang HTTP handler tila medyo marahas, 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.
Kami ay nakahilig patungo sa isang global.asax diskarte uri, higit sa lahat dahil naniniwala kami na magkakaroon kami ng mas pagpipilian para sa caching ng data sa puntong iyon.
Makikita ko ba ang pag-blog nang higit pa sa paksang ito bilang ko matuto nang higit pa.
Kung ikaw ay alam tungkol sa anumang bagay na ito, please post a comment 🙂
</dulo>
Sundin ako sa Twitter sa http://www.twitter.com/pagalvin
Hindi ko pa nasubok ito kaya hindi ako sigurado kung ito gumagana.
Ang Page klase ay may isang InitializeCulture() pamamaraan na maaaring mapatungan. Kung gagawin mo ito sa code sa likod ng iyong pasadyang masterpage, maaari mong gawin ang isang bagay kasama ang mga linya ng:
protektado override walang bisa InitializeCulture()
{
// override virtual na paraan InitializeCulture() upang suriin kung profile ay naglalaman ng isang user na setting ng wika
string UserCulture = GetCultureFromUserProfile();
kung ( UserCulture != "")
{
// mayroong isang gumagamit na setting ng wika sa profile: lumipat dito
Thread.CurrentThread.CurrentUICulture = bagong CultureInfo(UserCulture);
Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture(UserCulture);
}
}
Malinaw na maaari kang bumuo ng ilang mga pag-cache sa pagpapatupad ng ang paraan na ito.
Pinagmulan: http://quickstarts.asp.net/QuickStartv20/util/srcview.aspx?path = ~ / aspnet / sample / lokalisasyon / LocalizePers.src&file = LocalizePers_cs\LocalizePers_cs.aspx&lang = C 23% pinagmulan
Ako nag-iisip HTTP handler na may sumusunod na daloy:
1. Humiling pagdating sa, suriin ang cookies para sa isang session cookie para sa kagustuhan sa wika (session cookies ng bisa kapag ang browser ay sarado)
2. Suriin kung ang kahilingan ay para sa ASPX pahina, kung hindi, laktawan kahilingan
3. Kung mayroon na cookie, itakda ang wika ng header sa halaga na tinukoy. Ikaw ay tapos na!
4. Walang cookie, gawin ang mga kredensyal sa pagpapatotoo at hanapin ang mga gumagamit hanggang sa SPS, hanapin kagustuhan sa wika
5. Itakda ang cookie at header ng HTTP header wika. Tapos.
Unang pahina APX kahilingan ay magkakaroon ng overhead ng SPS lookup ngunit bawat kahilingan mula sa pagkatapos ay sa may walang lookup sa gayon ay magiging native na bilis. Walang mga pangangailangan para sa session cache o anumang iba pang overhead sa pamamagitan ng paggamit ng isang session cookie masyadong. Sa sandaling ang browser ay sarado, ang mga session cookie napupunta ang layo. Kung ang gumagamit ay nagbabago ang kanilang mga kagustuhan sa wika sa SPS kailangan lang nila upang isara at muling buksan ang browser para sa mga ito upang magkabisa.
talaga ang http handler ay hindi sa antas ng IIS…ito ay sa antas ng application (ISAPI Mga Filter ay sa antas ng IIS)…Gusto i-ingat BC SP ay may sarili nitong handler…kaya siguraduhin na subukan ito out…Gumawa ako nito bago ngunit nagkaroon ng ilang mga sumasalungat sa mga handler SP.
Gusto ko maging mas hilig upang gumamit ng isang HTTPHandler, ang tanging dahilan ay ang hindi ko gusto ng pagpindot sa mga file SharePoint. Plus madali upang lumikha ng isang SharePoint solusyon upang magtalaga ng isang HttHandler ( at gamitin ang SPWebConfig API ay upang baguhin ang web.config). Nagkakaroon ng mga gumagamit ng pagkarga gawin mo, Gusto kong isipin na mayroon kang isang malaki sakahan, mo ba talagang ayaw na pumunta modifiying mga file sa bawat server.
Deploy ang global.asa file sa pamamagitan ng isang solusyon ay isang masamang ideya, kung bawiin ito, ang iyong orihinal na file ay nawala …
Gayundin ang pagkakaroon ng kakayahan upang bawiin ang mga solusyon mabilis ay maaaring maging isang magandang ideya, kung sakali mga bagay pumunta sira ang perf ng handler.