Op mijn huidige project, Sommige van de gebruikers zal reizen over de hele wereld en wanneer ze op verschillende bestemmingen aankomen, gebruik welke machine is handig op het moment. Die gast machines Windows zal worden uitgevoerd en geïnstalleerd en geconfigureerd voor de lokale landinstelling. (Ik heb net realiseerde dat de gast machines niet de juiste taalpakketten wellicht… zal waarschijnlijk niet, Eigenlijk… Ik ben dat een voorlopig parking).
SharePoint moet voorzien in een mechanisme waarbij de gebruiker kan hun voorkeurstaal kiezen en vervolgens hebben MOSS eren die taal ongeacht hoe de gebruiker toegang krijgt MOSS tot. Met andere woorden, negeren wat de browser vertelt IIS/MOSS en in plaats daarvan dat voorkeurstaal opzoeken en gebruiken.
We gaan om te onderzoeken van twee benaderingen:
- HTTP-Handler: Een aangepaste HTTP-handler op IIS geïnstalleerd zal opzoeken MOSS-Profiel van de gebruiker, erachter te komen de gewenste taal en schakel de HTTP-header rond als nodig voordat controle doorgegeven aan MOSS.
- Global.asax: Wijzigen van global.asax om het zelfde ding doen. Wij kunnen iets anders wijzigen, maar het idee is dat we een plaats waar wij onze locale-switching logica kunt invoegen.
De andere complicerende factor is dat we ondersteuning 60k gebruikers moeten, over 1,000 van de toegang die worden gelijktijdig MOSS op hoogtepunt tot kan laden.
De HTTP-handler lijkt vrij drastische, maar misschien de beste plaats om de code te zetten aangezien er op het niveau van de IIS en alle-kent. Het is een goed één punt van werk.
We bent leunend naar een global.asax type aanpak, vooral omdat we geloven dat we hebben meer opties voor caching gegevens op dat moment.
Ik zal bloggen meer over dit onderwerp als ik meer leren.
Als u weet niets over dit, plaats alstublieft een reactie 🙂
</einde>
Volg mij op Twitter op http://www.twitter.com/pagalvin
Ik heb dit niet getest dus ik niet zeker ben of het werkt.
De Page-klasse heeft een InitializeCulture() methode die kan worden overschreven. Als u dit in de code achter van uw aangepaste masterpage doet, je zou kunnen doen iets in de trant van:
beschermde override void InitializeCulture()
{
// virtuele methode InitializeCulture overschrijven() om te controleren of profiel een taalinstelling van de gebruiker bevat
UserCulture koord = GetCultureFromUserProfile();
Als ( UserCulture != "")
{
// Er is een taalinstelling van de gebruiker in het profiel: Schakel over naar het
Thread.CurrentThread.CurrentUICulture = nieuwe CultureInfo-waarde(UserCulture);
Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture(UserCulture);
}
}
Uiteraard kunt u bouwen sommige caching in de uitvoering van deze methode.
Bron: http://quickstarts.asp.net/QuickStartv20/util/srcview.aspx?Path=~/ASPNET/samples/localization/LocalizePers.src&bestand = LocalizePers_cs\LocalizePers_cs.aspx&lang = C % 23 bron
Ik denk HTTP-handler met de volgende stroom:
1. Aanvraag binnenkomt, cookies voor een sessie-cookie voor taalvoorkeur controleren (sessiecookies verlopen wanneer de browser wordt gesloten)
2. Controleren of verzoek voor ASPX-pagina, Zoniet, verzoek overslaan
3. Als de cookie bestaat, de taal-header ingesteld op de waarde die is opgegeven. U klaar bent!
4. Geen cookie, Neem de referentie van de verificatie en de gebruiker opzoeken in SPS, Taalvoorkeur vinden
5. Instellen van cookie- en HTTP taal header. Gedaan.
Eerste APX paginaverzoek overhead voor SPS lookup zal hebben maar elk verzoek voortaan met hebben geen zoekacties zodat zullen inheemse snelheid. Geen behoefte aan sessie cache of elke andere overhead met behulp van een sessie-cookie ook. Zodra de browser wordt gesloten, de sessie-cookie gaat weg. Als de gebruiker de voorkeur van hun talen in SPS wijzigt hoeft ze alleen maar om te sluiten en opnieuw openen van de browser voor het pas van kracht.
eigenlijk is de http-handler niet op het niveau van iis…het is op het niveau van de toepassing (ISAPI-Filters zijn op het niveau van IIS)…Ik zou voorzichtig zijn dat BC SP heeft zijn eigen handler…dus zorg ervoor dat het uit te testen…Ik heb het eerder gedaan, maar hebben sommige conflict met de SP-handler.
Ik zou meer geneigd om te gebruiken een HTTPHandler, de enige reden is dat ik hou niet aanraken van de SharePoint-bestanden. Plus het is gemakkelijk om een SharePoint-oplossing voor het implementeren van een HttHandler te maken ( en de SPWebConfig API's gebruiken om te wijzigen de web.config). Met de gebruiker belasting jij, Ik zou voorstellen dat u hebben een omvangrijke boerderij, je echt wilt niet om te gaan modifiying bestanden op elke server.
Het global.asa-bestand via een oplossing implementeren is een slecht idee, Als u het intrekken, het oorspronkelijke bestand is verdwenen …
Ook met de mogelijkheid om de oplossing snel intrekken wellicht een goed idee, in het geval dat dingen misgaan met de première van de handler.