Na moj trenutni projekt, neki od korisnika će putovati po svijetu i kad dođe na različitim destinacijama, use whatever machine is handy at the time. Those guest machines will be running Windows and installed and configured for the local locale. (Upravo sam shvatio da nijedne strojevi ne mogu imati prave jezične pakete… vjerojatno neće, zapravo… Ja sam parkirao na taj jedan za sada).
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.
Mi ćemo istražiti dva pristupa:
- HTTP Handler: Prilagođeni HTTP rukovatelj instaliran na IIS će pogledati korisnikov profil MOSS, shvatiti željeni jezik, a zatim se prebacite na HTTP zaglavlje oko koliko je potrebno prije donošenja kontrolu 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.
Drugi otežavajući čimbenik je da trebamo podržati 60k korisnika, oko 1,000 od kojih se može istovremeno biti pristup Moss, na vršnog opterećenja.
HTTP rukovatelj čini prilično drastične, 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.
Mi smo naginje prema global.asax tipa pristupa, uglavnom zbog toga što vjerujemo da ćemo imati više mogućnosti za caching podataka u tom trenutku.
Ja ću biti blogging više o ovoj temi kao što sam saznati više.
Ako znate ništa o tome, please post a comment 🙂
</kraj>
Slijedite me na Twitter-u http://www.twitter.com/pagalvin
Ja se ne su se testirani je ovo, tako Ja sam ne siguran ako je to radi.
Page klasa ima jedan InitializeCulture() metoda koja može biti pregažen. Ako ste učinite je ovo u kodu iza sebe of vašem prilagođenom masterpage, ste bi mogao učinite nešto uzduž linije od:
zaštićeno nadjačavanje void InitializeCulture()
{
// nadjačati virtualnu InitializeCulture metodu() kako bi provjerili ako je Profil sadrži postavku korisnički jezičnu
string UserCulture = GetCultureFromUserProfile();
ako ( UserCulture != "")
{
// postoji postavka korisnički jezik u na profilu: se prebaciti na njega
Thread.CurrentThread.CurrentUICulture = new CultureInfo(UserCulture);
Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture(UserCulture);
}
}
Očito ste može graditi neki caching u provedbi od ovom metodom.
Izvor: http://quickstarts.asp.net/QuickStartv20/util/srcview.aspx?path = ~ / ASPNet / Uzorci / lokalizacije / LocalizePers.src&file = LocalizePers_cs\LocalizePers_cs.aspx&lang = C 23% izvor
Razmišljam HTTP rukovatelj sa sljedećim toka:
1. Zahtjev dolazi u, provjeriti kolačiće za kolačić sesije za jezik sučelja (session cookies istječe kada browser zatvoren)
2. Provjerite je li zahtjev za aspx stranici, ako ne i, preskočite zahtjev
3. Ako postoji Kolačić, postaviti zaglavlje jezika na vrijednost navedenu. Vi ste učinili!
4. Ne Kolačić, uzeti uvjerenje provjeru i tražiti korisnika u SPS, pronaći jezik sučelja
5. Postavite kolačić zaglavlja i HTTP zaglavlja jezik. Sastavljeno.
Prvo APX stranica Zahtjev će imati nadzemne SPS pretraživanja, ali svaki zahtjev od tada sa nemamo dohvate, tako će biti materinji brzina. Nema potrebe za sjednice cache ili bilo koje druge nadzemne pomoću kolačić sesije previše. Nakon preglednik je zatvorena, Kolačić sesije ide dalje. Ako korisnik promijeni svoje preference jezika u SPS-a oni samo morati zatvoriti i ponovno otvoriti preglednik za to da se učinak.
zapravo http rukovatelj nije na razini IIS…to je na razini aplikacije (ISAPI Filteri su na IIS razini)…ja bih biti oprezan prije Krista SP ima svoju rukovatelj…pa budite sigurni da test it out…Ja sam to učinio prije, ali su imali neki sukob sa SP rukovatelj.
Ja bih bio skloniji koristiti HTTPHandler, Jedini razlog je što mi se ne sviđa dodirivanje SharePoint datoteka. Plus to je lako stvoriti SharePoint rješenja za implementaciju HttHandler ( i koristiti SPWebConfig API-a za izmjenu web.config). Nakon što je korisničko opterećenje što činite, Ja bih zamisliti da imate poveliki farmu, stvarno ne želim ići modifiying datoteke na svakom poslužitelju.
Postavljanje je global.asa datoteku putem rješenja je loša ideja, ako ga povući, svoju izvornu datoteku je otišao …
Također ima sposobnost da brzo uvlačenje rješenje bi moglo biti dobra ideja, u slučaju da stvari krenu krivo s perf od rukovatelj.