Min aktuelle projekt, nogle af brugerne vil rejse rundt omkring i verden, og når de ankommer til forskellige destinationer, bruge uanset maskine er handy dengang. Disse gæstcomputere, der vil køre Windows og installeret og konfigureret for den lokale landestandard. (Jeg har lige indset, at gæst apparater ikke kan have de rigtige sprogpakker… sandsynligvis ikke, Faktisk… Jeg parkering at man nu).
SharePoint skal give en mekanisme, hvorved brugeren kan vælge deres foretrukne sprog og derefter har mos ære at sprog uanset hvordan brugeren får adgang til MOSS. Med andre ord, Se bort fra hvad browseren fortæller IIS/mos og i stedet slå det foretrukne sprog og bruge det.
Vi vil undersøge to tilgange:
- Http-handleren: En brugerdefineret http-handleren installeret på IIS vil slå op MOSS brugerprofil, finde ud af det foretrukne sprog og derefter skifte http-headeren rundt efter behov inden de passerer kontrollen til MOSS.
- Global.asax: Ændre global.asax for at gøre det samme. Vi kan ændre noget andet, men ideen er, at vi finder et sted hvor vi kan indsætte vores locale-switching logik.
Den andre komplicerende faktor er, at vi skal støtte 60k brugere, om 1,000 der kan samtidig adgang mos på højeste belastning.
Http-handleren synes temmelig drastiske, men måske det bedste sted at sætte koden, da det er på IIS niveau og alvidende. Det er en god enkelt punkt af arbejde.
Vi hælder mod en global.asax type tilgang, især fordi vi mener, har vi flere muligheder for at cachelagre data på det tidspunkt.
Jeg vil være blogging mere om dette emne, som jeg lære mere.
Hvis du har ved noget om dette, please post a comment 🙂
</slutningen>
Følg mig på kvidre på http://www.twitter.com/pagalvin
Jeg har ikke testet dette, så jeg ikke er sikker på om det virker.
Klassen side har en InitializeCulture() metode, der kan tilsidesættes. Hvis du gøre dette i programkode bag af din brugerdefineret masterside, du kunne gøre noget i retning af:
beskyttede override annullere InitializeCulture()
{
// tilsidesætte virtuel metode InitializeCulture() kontrollere hvis profil indeholder sproget en brugerindstilling
string UserCulture = GetCultureFromUserProfile();
Hvis ( UserCulture != "")
{
// der er en bruger sprogindstillingen i profilen: skifte til det
Thread.CurrentThread.CurrentUICulture = ny CultureInfo(UserCulture);
Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture(UserCulture);
}
}
Naturligvis kan du bygge nogle cacheing i gennemførelsen af denne metode.
Kilde: http://quickstarts.asp.net/QuickStartv20/util/srcview.aspx?Path=~/ASPNET/samples/localization/LocalizePers.src&fil = LocalizePers_cs\LocalizePers_cs.aspx&lang = C % 23 kilde
Jeg tænker http-handler med de følgende flow:
1. Anmodningen kommer, kontrollere cookies for en sessionscookie for sprogindstilling (Sessionscookies udløber, når browseren er lukket)
2. Kontroller, om anmodningen er for ASPX-side, Hvis ikke, springe anmodning
3. Hvis cookie findes, angive sprog overskrift til den angivne værdi. Du er færdig!
4. Ingen cookie, tage godkendelse legitimationsoplysninger og ser brugeren i SPS, Find foretrukne sprog
5. Indstille cookie header og http-sprog header. Gjort.
Første APX sideanmodning vil have overhead af SPS opslag men hver anmodning fra da af med har ingen opslag så bliver indfødte hastighed. Intet behov for sessionscachen eller nogen andre overhead ved hjælp af en sessionscookie for. Når browseren er lukket, sessionscookie går væk. Hvis brugeren ændrer deres sprog præference i SPS skal de bare lukke og genåbne browser at træde i kraft.
faktisk http-handleren ikke på iis-niveau…Det er på programniveau (ISAPI-filtre er på IIS-niveau)…Jeg ville være forsigtig bc SP har sin egen handleren…så sørg for at prøve det af…Jeg har gjort det før men har haft nogle konflikter hos manipulere med SP.
Jeg ville være mere tilbøjelige til at bruge en HTTPHandler, den eneste grund er, at jeg ikke kan lide at røre SharePoint filer. Plus det er nemt at oprette en SharePoint-løsning for at implementere en HttHandler ( og bruge API'EN SPWebConfig til at ændre web.config). At have brugerbelastningen gøre du, Jeg kan forestille mig, du har en anselig gård, du virkelig ønsker ikke at gå modifiying filer på hver server.
Installation af filen global.asa via en løsning er en dårlig idé, Hvis du trække det, din oprindelige fil er borte …
Også har mulighed for at trække løsningen hurtigt kan være en god idé, i tilfælde af at noget går galt med perf af handleren.